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Foreword 



rd , 



This Technical Specification has been produced by the 3 Generation Partnership Project (3GPP). 

The contents of the present document are subject to continuing work within the TSG and may change following formal 
TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an 
identifying change of release date and an increase in version number as follows: 

Version x.y.z 

where: 

X the first digit: 

1 presented to TSG for information; 

2 presented to TSG for approval; 

3 or greater indicates TSG approved document under change control. 

y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, 
updates, etc. 

z the third digit is incremented when editorial only changes have been incorporated in the document. 



Introduction 



The present document is the first part of a multi-part conformance specification valid for 3GPP Release 5 and later 
releases. 

3GPP TS 34.229-1 (the present document): Internet Protocol (IP) multimedia call control protocol based 
on Session Initiation Protocol (SIP) and Session Description Protocol (SDP); User Equipment (UE) 
conformance specification; Part 1: Protocol conformance specification- current document. 

3GPP TS 34.229-2 [5]: "Internet Protocol (IP) multimedia call control protocol based on Session Initiation 
Protocol (SIP) and Session Description Protocol (SDP); User Equipment (UE) conformance specification; Part 2: 
Implementation Conformance Statement (ICS) proforma specification". 

3GPP TS 34.229-3 [6]: "Internet Protocol (IP) multimedia call control protocol based on Session Initiation 
Protocol (SIP) and Session Description Protocol (SDP); User Equipment (UE) conformance specification; Part 3: 
Abstract Test Suites (ATS)". 

Note 1: The ATS is written in a standard testing language, TTCN-3, as defined in ETSI ES 201 873 Parts 1 to 3 
[36] [37] [38]. 

Note 2: For conformance testing of the UTRAN requirements refer to 3GPP TS 34. 123 Parts 1 to 3 [2] [3] [4]. 

Note 3: Further information on testing can be found in ETSI ETS 300 406 [9] and ISO/IEC 9646-1 [7]. 

For at least a minimum set of services, the prose descriptions of test cases will have a matching detailed test case 
implemented in TTCN-3 (and provided in 3GPP TS 34.229-3 [6]). 
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Scope 



The present document specifies the protocol conformance testing for the User Equipment (UE) supporting the Internet 
Protocol (IP) multimedia call control protocol based on Session Initiation Protocol (SIP) and Session Description 
Protocol (SDP). 

This is the first part of a multi-part test specification. The following information can be found in this part: 

the overall test structure; 

the test configurations; 

the conformance requirement and reference to the core specifications; 

the test purposes; and 

a brief description of the test procedure, the specific test requirements and short message exchange table. 
The following information relevant to testing can be found in accompanying specifications: 

the applicability of each test case [5]. 

A detailed description of the expected sequence of messages can be found in the 3'^'^ part of present test specification [6]. 

The Implementation Conformance Statement (ICS) pro-forma can be found in the 2"'^ part of the present test 
specification [5]. 

The present document is valid for UE implemented according to 3GPP Releases starting from Release 5 up to the 
Release indicated on the cover page of the present document. 
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Release as the present document. 
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Conformance Statement (ICS) proforma specification". 
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(ATS)". 
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3 Definitions, symbols and abbreviations 

For the purposes of the present document, the terms and definitions given in TR 21.905 [1] and the following apply. A 
term defined in the present document takes precedence over the definition of the same term, if any, in TR 2 1 .905 [ 1 ] . 

3.1 Definitions 

For the purposes of the present document, the following additional abbreviations apply: 
example: text used to clarify abstract rules by applying them literally 
Floor: Floor(x) is the largest integer smaller than or equal to x. 
Ceil: Ceil (x) is the smallest integer larger than or equal to x. 

3.2 Symbols 

For the purposes of the present document, the following additional symbols apply: 
None. 

3.3 Abbreviations 

For the purposes of the present document, the following abbreviations apply: 

AAAA Address (IP v6) 

AKA Authentication and Key Agreement 

AKAvl-MD5 Authentication and Key Agreement version 1- Message-Digest 5 

DUID DHCP Unique Identifier 

FQDN Fully Qualified Domain Name 

HMAC-MD5-96 Hashing for Message Authentication Code - Message-Digest 5-96 (bits) 

HMAC-SHA-1-96 Hashing for Message Authentication Code - Secure Hash Algorithm 1 - 96 (bits) 

ICS Implementation Conformance Statement 

IN INternet 

IPsec IP Security 

IXIT Implementation eXtra Information for Testing 

MIME Multi purpose Internet Mail Extensions 

NAPTR Naming Authority Pointer 

P-CSCF Proxy - Call Session Control Function 

RTCP Real Time Transport Control Protocol 

SIGComp SIGnalling Compression 

SRV SeRVice 

SS System Simulator 



4 Overview 

4.1 Test Methodology 

4.1 .1 Testing of optional functions and procedures 

Any function or procedure which is optional, as indicated in the present document, may be subject to a conformance test 
if it is implemented in the UE. 

A declaration by the apparatus supplier (Implementation Conformance Statement (ICS)) is used to determine whether 
an optional function/procedure has been implemented (see ISO/IEC 9646-7 [8] for general information about ICS). 
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4.2 Implicit Testing 



For some 3GPP signalling and protocol features conformance is not verified explicitly in the present document. This 
does not imply that correct functioning of these features is not essential, but that these are implicitly tested to a 
sufficient degree in other tests. 



4.3 Conformance Requirements 



The Conformance Requirements clauses in the present document are copy/paste from the relevant core specification 
where skipped text have been replaced with "...". References to clauses in the Conformance Requirements section of the 
test body refers to clauses in the referred specification, not sections in the present document. 



Reference Conditions 



The test cases are expected to be executed through the 3GPP radio interface. Details of the radio interfaces are outside 
the scope of this specification. The reference environments used by tests are specified in the test. 



5.1 Generic setup procedures 



A set of basic generic procedures for PDP Context Activation, P-CSCF Discovery and Registration are described in 
Annex C. These procedures are used in numerous test cases throughout the present document. 



6 PDP Context Activation 

6.1 General Purpose PDP Context Establishment 

Implicitly tested. 

Note: This is implicitly tested as part of generic procedures. 

6.2 General Purpose PDP Context Establishment (UE 
Requests for a Dedicated PDP Context) 

6.2.1 Definition 

Test to verify that the UE can establish a "General Purpose PDP context" for SIP signalling. 

6.2.2 Conformance requirement 

Prior to communication with the IM CN subsystem, the UE shall 

a) perform a GPRS attach procedure; 

b) establish a PDP context used for SIP signalling according to the APN and GGSN selection criteria described in 
3GPP TS 23.060 and 3GPP TS 27.060 . This PDP context shall remain active throughout the period the UE is 
connected to the IM CN subsystem, i.e. from the initial registration and at least until the deregistration. As a 
result, the PDP context provides the UE with information that makes the UE able to construct an IPv6 address; 

The UE shall choose one of the following options when performing establishment of this PDP context: 

I 

II. A general-purpose PDP context: 
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The UE may decide to use a general-purpose PDP Context to carry IM CN subsystem-related signaling. The 
UE shall indicate to the GGSN that this is a general-purpose PDP context by not setting the IM CN 
Subsystem Signalling Flag. The UE may carry both signalling and media on the general-purpose PDP 
context. The UE can also set the Signalling Indication attribute within the QoS IE. 

The UE indicates the IM CN Subsystem Signalling Flag to the GGSN within the Protocol Configuration Options 
IE of the ACTIVATE PDP CONTEXT REQUEST message or ACTIVATE SECONDARY PDP CONTEXT 
REQUEST message. Upon successful signalling PDP context establishment the UE receives an indication from 
GGSN in the form of IM CN Subsystem Signalling Flag within the Protocol Configuration Options IE. If the 
flag is not received, the UE shall consider the PDP context as a general-purpose PDP context. 

The encoding of the IM CN Subsystem Signalling Flag within the Protocol Configuration Options IE is 
described in 3GPP TS 24.008 . 

Reference(s) 

3GPPTS 24.229[10], clause 9.2.1 

6.2.3 Test purpose 

To verify that the UE sends a correctly composed Activate PDP context request by setting the IM CN Subsystem 
Signalling Flag to the GGSN within the Protocol Configuration Options IE. 

On receiving Activate PDP Context accept with IM CN Subsystem Signalling Flag not set within the Protocol 
Configuration Options IE, UE shall consider the PDP context as a General Purpose PDP context for SIP signalling . 

6.2.4 Method of test 

Initial conditions 

The UE is in GMM-state "GMM-REGISTERED, normal service" with valid P-TMSI and CKSN. UE is not registered 
to IMS services, has not established PDP context for IMS 

Related ICS/IXIT Statement(s) 

UE capable of being configured to initiate Dedicated PDP Context (Yes/No) 
UE Supports IPv4 (Yes/No) 
UE Supports IPv6 (Yes/No) 

Test procedure 

1) UE is configured for setting the IM CN Subsystem Signalling Flag to the GGSN within the Protocol 
Configuration Options IE in Activate PDP Context Request message. UE initiates an Activate PDP Context 
procedure. 

2) SS Responds with an Activate PDP Context Accept message by not setting IM CN Subsystem Signalling Flag 
within the Protocol Configuration Options IE 

3) UE is made to continue with Registration procedure. Annex C, step 3. 
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Step 


Direction 


Message 


Comment 


UE 1 SS 


1 


^ 


Activate PDP Context Request 


UE sends tliis PDU by setting the IIVI CN 
Subsystem Signalling Flag to the GGSN within the 
Protocol Configuration Options IE 


2 


^ 


Activate PDP Context Accept 


SS Sends this response by not setting IM CN 
Subsystem Signalling Flag within the Protocol 
Configuration Options IE 


3 


-^•^ 


Initiate Annex C step 3 


UE is made to continue with Registration procedure 
Annex C step 3 



Specific Message Contents: 

Activate PDP Context Request (step 1) 



IE 


Value/Remarl<s 


Protocol Configuration options 
- Additional Parameters 
-- container 1 Identifier 
-- Container 1 Length 


* 

0002H (IIVI CN Subsystem Signaling Flag) 
bytes 



*Note: UE may include additional containers also. If multiple containers are present they can be in any order. 
Activate PDP Context Accept (step 2) 
Case 1 : UE supports IPv6 / IPv6 and IPv4 



IE 


Value/Remarks 


Protocol Configuration options 




- Additional Parameters 




- container 1 Identifier 


0001 H (P-CSCF Address) (Included if "P-CSCF Server 




Address Request" is received) 


-- Container 1 Length 


1 6 bytes 


-- Container 1 contents 


IPV6 address of SS P-CSCF Server 


-- container 2 Identifier 


0003H (DNS Address) (Included if "DNS Server Address 




Request" is received) 


-- Container 2 Length 


1 6 bytes 


-- Container 2 contents 


IPV6 address of SS DNS Server 



Case 2: UE supports only IPv4 



IE 


Value/Remarks 


Protocol Configuration options 




- Additional Parameters 




-- container 1 Identifier 


0001 H (P-CSCF Address) 


-- Container 1 Length 


1 6 bytes 


-- Container 1 contents 


IPV4 address of SS P-CSCF encoded as per 3GPP TR 




23.981 [35] 


-- container 2 Identifier 


0003H (DNS Address) (Included if "DNS Server Address 




Request" is received) 


-- Container 2 Length 


1 6 bytes 


-- Container 2 contents 


IPV4 address of SS DNS server encoded as per 3GPP 




TR23.981[351 



6.2.5 Test requirements 



1) In step 1, UE sets the IM CN Subsystem Signalling Flag to the GGSN within the Protocol Configuration Options 
IE. 
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2) After step 2, UE shall consider the PDP context as a general purpose PDP context for SIP signalling and 
continue with Registration procedure in Annex C.2 step 3. 

6.3 Dedicated PDP Context Establishment 

6.3.1 Definition 

Test to verify that the UE can establish a "Dedicated PDP context" for SIP signalling. 

6.3.2 Conformance requirement 

A. Prior to communication with the IM CN subsystem, the UE shall: 

a) perform a GPRS attach procedure; 

b) establish a PDP context used for SIP signalling according to the APN and GGSN selection criteria described in 
3GPP TS 23.060 and 3GPP TS 27.060 . This PDP context shall remain active throughout the period the UE is 
connected to the IM CN subsystem, i.e. from the initial registration and at least until the deregistration. As a 
result, the PDP context provides the UE with information that makes the UE able to construct an IPv6 address; 

The UE shall choose one of the following options when performing establishment of this PDP context: 

I. A dedicated PDP context for SIP signalling: 

The UE shall indicate to the GGSN that this is a PDP context intended to carry IM CN subsystem-related 
signalling only by setting the IM CN Subsystem Signalling Flag. The UE may also use this PDP context for 
DNS and DHCP signalling according to the static packet filters as described in 3GPP TS 29.061 . The UE 
can also set the Signalling Indication attribute within the QoS IE; 

II. A general-purpose PDP context: 

The UE may decide to use a general-purpose PDP Context to carry IM CN subsystem-related signaling. The 
UE shall indicate to the GGSN that this is a general-purpose PDP context by not setting the IM CN 
Subsystem Signalling Flag. The UE may carry both signalling and media on the general-purpose PDP 
context. The UE can also set the Signalling Indication attribute within the QoS IE. 

The UE indicates the IM CN Subsystem Signalling Flag to the GGSN within the Protocol Configuration Options 
IE of the ACTIVATE PDP CONTEXT REQUEST message or ACTIVATE SECONDARY PDP CONTEXT 
REQUEST message. Upon successful signalling PDP context establishment the UE receives an indication from 
GGSN in the form of IM CN Subsystem Signalling Flag within the Protocol Configuration Options IE. If the 
flag is not received, the UE shall consider the PDP context as a general-purpose PDP context. 

The encoding of the IM CN Subsystem Signalling Flag within the Protocol Configuration Options IE is 
described in 3GPP TS 24.008 . 

Reference(s) 

3GPPTS 24.229[10], clause 9.2.1. 

6.3.3 Test purpose 

To verify that on receiving Activate PDP Context accept with IM CN Subsystem Signalling Flag included within the 
Protocol Configuration Options IE, UE shall consider the PDP context as a Dedicated PDP context for SIP signalling. 

6.3.4 Metliod of test 

Initial conditions 

The UE is in GMM-state "GMM-REGISTERED, normal service" with valid P-TMSI and CKSN. UE is not registered 
to IMS services, has not established PDP context. 
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Related ICS/IXIT Statement(s) 

UE capable of being configured to initiate Dedicated PDP Context (Yes/No) 
UE Supports IPv4 (Yes/No) 
UE Supports IPv6 (Yes/No) 

Test procedure 

1) UE is configured for setting the IM CN Subsystem Signalling Flag to the GGSN within the Protocol 
Configuration Options IE in Activate PDP Context Request message. UE initiates an Activate PDP Context 
procedure. 

2) SS Responds with an Activate PDP Context Accept message by including IM CN Subsystem Signalling Flag 
within the Protocol Configuration Options IE 

3) UE is made to continue with Registration procedure, Annex C, step 3. 
Expected sequence 



Step 


Direction 


IViessage 


Comment 


UE 1 SS 


1 


^ 


Activate PDP Context Request 


UE sends tliis PDU by setting tine IIVI CN 
Subsystem Signalling Flag to the GGSN within the 
Protocol Configuration Options IE 


2 


-^ 


Activate PDP Context Accept 


SS Sends this response by including IM CN 
Subsystem Signalling Flag within the Protocol 
Configuration Options IE 


3 


<-^ 


Initiate Annex C step 3 


UE is made to continue with Registration procedure 
Annex C step 3 



Specific Message Contents: 

Activate PDP Context Request (step 1) 



IE 


Value/Remarks 


Protocol Configuration options 

- Additional Parameters 

- container 1 Identifier 
-- Container 1 Length 


0002H (IIVI CN Subsystem Signaling Flag) 
bytes 



* Note: UE may include additional containers also. If multiple containers are present they can be in any order. 
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Activate PDP Context Accept (step 2) 
Case 1 : UE supports IPv6 / IPv6 and IPv4 



IE 


Value/Remarks 


Protocol Configuration options 




- Additional Parameters 




-- container 1 Identifier 


0002H (IM CN Subsystem Signaling Flag) 


-- Container 1 Length 


bytes 


- container 2 Identifier 


0001 H (P-CSCF Address) (Included if "P-CSCF Server 




Address Request" is received) 


-- Container 2 Length 


1 6 bytes 


-- Container 2 contents 


IPV6 address of SS P-CSCF Server 


- container 3 Identifier 


0003H (DNS Address) (Included if "DNS Server Address 




Request" is received) 


-- Container 3 Length 


1 6 bytes 


-- Container 3 contents 


IPV6 address of SS DNS Server 



Case 2: UE supports only IPv4 



IE 


Value/Remarks 


Protocol Configuration options 




- Additional Parameters 




- container 1 Identifier 


0002H (IM CN Subsystem Signaling Flag) 


-- Container 1 Length 


bytes 


- container 2 Identifier 


0001 H (P-CSCF Address) 


-- Container 2 Length 


1 6 bytes 


-- Container 2 contents 


IPV4 address of SS P-CSCF encoded as per 3GPP TR 




23.981 


-- container 3 Identifier 


0003H (DNS Address) (Included if "DNS Server Address 




Request" is received) 


-- Container 3 Length 


1 6 bytes 


-- Container 3 contents 


IPV4 address of SS DNS server encoded as per 3GPP 




TR 23.981 [35] 



6.3.5 Test requirements 



1) In step 1, UE sets the IM CN Subsystem Signalling Flag to the GGSN within the Protocol Configuration Options 
IE. 

2) After step 2, UE shall consider the PDP context as a dedicated PDP context for SIP signalling and continue with 
Registration procedure in Annex C.2 step 3 



7 P-CSCF Discovery 

7.1 P-CSCF Discovery via PDP Context 



7.1.1 



Definition 



Test to verify that the UE can establish a PDP context for SIP signalling and acquire P-CSCF address(es) during PDP 
Context Activation procedure. 

7.1.2 Conformance requirement 

Prior to communication with the IM CN subsystem, the UE shall: 
a) perform a GPRS attach procedure; 
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b) establish a PDP context used for SIP signalling according to the APN and GGSN selection criteria described in 
3GPP TS 23.060 and 3GPP TS 27.060 . This PDP context shall remain active throughout the period the UE is 
connected to the IM CN subsystem, i.e. from the initial registration and at least until the deregistration. As a 
result, the PDP context provides the UE with information that makes the UE able to construct an IPv6 address; 

The UE shall choose one of the following options when performing establishment of this PDP context: 

L ... 

II. A general-purpose PDP context: 

The UE may decide to use a general-purpose PDP Context to carry IM CN subsystem-related signaling. The 
UE shall indicate to the GGSN that this is a general-purpose PDP context by not setting the IM CN 
Subsystem Signalling Flag. The UE may carry both signalling and media on the general-purpose PDP 
context. The UE can also set the Signalling Indication attribute within the QoS IE. 

The UE indicates the IM CN Subsystem Signalling Flag to the GGSN within the Protocol Configuration Options 
IE of the ACTIVATE PDP CONTEXT REQUEST message or ACTIVATE SECONDARY PDP CONTEXT 
REQUEST message. Upon successful signalling PDP context establishment the UE receives an indication from 
GGSN in the form of IM CN Subsystem Signalling Flag within the Protocol Configuration Options IE. If the 
flag is not received, the UE shall consider the PDP context as a general-purpose PDP context. 

The encoding of the IM CN Subsystem Signalling Flag within the Protocol Configuration Options IE is 
described in 3GPP TS 24.008. 

The UE can indicate a request for prioritised handling over the radio interface by setting the Signalling 
Indication attribute (see 3GPP TS 23.107 [4A]). The general QoS negotiation mechanism and the encoding of 
the Signalling Indication attribute within the QoS IE are described in 3GPP TS 24.008 . 

NOTE: A general-purpose PDP Context may carry both IM CN subsystem signaling and media, in case the media 
does not need to be authorized by Service Based Local Policy mechanisms defined in 3GPP TS 29.207 
and the media stream is not mandated by the P-CSCF to be carried in a separate PDP Context. 

c) acquire a P-CSCF address(es). 

The methods for P-CSCF discovery are: 

L ... 

II. Transfer P-CSCF address(es) within the PDP context activation procedure. 

The UE shall indicate the request for a P-CSCF address to the GGSN within the Protocol Configuration 
Options IE of the ACTIVATE PDP CONTEXT REQUEST message or ACTIVATE SECONDARY PDP 
CONTEXT REQUEST message. 

If the GGSN provides the UE with a list of P-CSCF IPv6 addresses in the ACTIVATE PDP CONTEXT 
ACCEPT message or ACTIVATE SECONDARY PDP CONTEXT ACCEPT message, the UE shall assume 
that the list is prioritised with the first address within the Protocol Configuration Options IE as the P-CSCF 
address with the highest priority. 

From 23.981 [35]: 

The existing P-CSCF discovery mechanism are either IPv6 specific or use Release 5 or later GPRS. For an IPv4 based 
IMS implementation, operators may need other mechanisms not currently defined as possible options in 3GPP IMS. 

The following mechanisms need to be evaluated for P-CSCF discovery in IPv4: 

a) the address of the P-CSCF can be requested by the UE and returned by the GGSN at PDP context establishment 
time. An IPv4 UE would need to obtain an IPv4 address as part of this exchange. 

If the PDP context established is of PDP type IPv4, then the GGSN may provide an IPv4 P-CSCF address. This 
does not preclude scenarios, where the GGSN returns an IPv6 P-CSCF address at IPv4 PDP context 
establishment, e.g. for the support of tunnelling (see subclause 5.3.4.3), or both IPv4 and IPv6 P-CSCF 
addresses. If the PDP type is IPv4 then it is recommended that the GGSN always return both IP versions, if it is 
capable, using the existing capabilities to send multiple P-CSCF addresses within the PCO IE. 
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According to TS 24.008, the P-CSCF address in the PCO field is an IPv6 address. Thus there are at least two 
possible approaches: The first approach would be to avoid any changes to or deviations from TS 24.008 and use 
the existing methods to transfer an IPv4 address as an IPv6 address ('TPv6 address with embedded IPv4 
address", as defined in RFC 2373. 

Reference(s) 

3GPPTS 24.229[10], clause 9.2.1, 3GPPTR 23.981[35], clause 5.2.1 



7.1.3 Test purpose 



To verify that the UE sends a correctly composed Activate PDP context request message requesting for P-CSCF 
address(es) to the GGSN within the Protocol Configuration Options IE. 

On receiving Activate PDP Context accept with IM CN Subsystem Signalling Flag not included within the Protocol 
Configuration Options IE and list of P-CSCF IPv6/IPv4 addresses included, UE shall consider the PDP context as a 
general purpose PDP context for SIP signalling and P-CSCF discovery procedure to be successful. 

7.1.4 Method Of test 

Initial conditions 

The UE is in GMM-state "GMM-REGISTERED, normal service" with valid P-TMSI and CKSN. UE is not registered 
to IMS services, has not established PDP context for IMS. 

Related IGS/IXIT Statement(s) 
UE Supports IPv4 (Yes/No) 
UE Supports IPv6 (Yes/No) 
UE capable of being configured to initiate P-CSCF Discovery via PCO (Yes/No) 

Test procedure 

1) UE is configured for setting request for a P-CSCF address to the GGSN within the Protocol Configuration 
Options IE in Activate PDP Context Request message. UE initiates an Activate PDP Context procedure. 

2) SS responds with an Activate PDP Context Accept including list of P-CSCF IPv6 and IPv4 addresses. IPv4 
addresses are encoded as per 23.981 [35] clause 5.2.1 

3) UE is made to initiate Registration procedure for IMS services. 
Expected sequence 



Step 


Direction 


Message 


Comment 


UE 1 SS 


1 


^ 


Activate PDP Context Request 


UE sends this PDU by setting request for P-CSCF 
address{es) to the GGSN within the Protocol 
Configuration Options IE 


2 


<- 


Activate PDP Context Accept 


SS Sends this response byincluding list of P-CSCF 
addresses 


3 


-^-> 


Registration 


UE is made to initiate Registration procedure to IIVIS 
services as defined in Annex C Generic 
Registration Procedure. 



NOTE: The test sequence is identical for IPv4 and IPv6 except the message contents of Activate PDP Context 
Accept message. For a UE supporting both IPv4 and IPv6, only IPv6 option need to be executed. 
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IE 


Value/Remarks 


Protocol Configuration options 




- Additional Parameters 




-- container 1 Identifier 


0001 H (P-CSCF Address Request); 


-- Container 1 Length 


bytes 


-- container 2 Identifier 


0003H (DNS Server Address Request) (Optional) 


-- Container 2 Length 


bytes 



Activate PDP Context Accept (step 2) 
Case 1 : UE supports IPv6 / IPv6 and IPv4 



IE 


Value/Remarks 


Protocol Configuration options 




- Additional Parameters 




-- container 1 Identifier 


0001 H (P-CSCF Address) 


-- Container 1 Length 


1 6 bytes 


-- Container 1 contents 


IPV6 address of SS P-CSCF Server 


- container 2 Identifier 


0003H (DNS Address) (Included if "DNS Server Address 




Request" is received) 


-- Container 2 Length 


1 6 bytes 


-- Container 2 contents 


IPV6 address of SS DNS Server 



Case 2: UE supports only IPv4 



IE 


Value/Remarks 


- Additional Parameters 




Protocol Configuration options 

- Additional Parameters 

- container 2 Identifier 

- Container 2 Length 

- Container 2 contents 

- container 3 Identifier 

- Container 3 Length 

- Container 3 contents 


0001 H (P-CSCF Address) 

1 6 bytes 

IPV4 address of SS encoded as per 3GPP TR 23.981 [35] 

0003H (DNS Address) (Included if "DNS Server Address 

Request" is received) 

1 6 bytes 

IPV4 address of SS DNS server encoded as per 3GPP 

TR 23.981 [35] 



7.1 .5 Test requirements 

1) In step 1, UE requests for P-CSCF address to the GGSN within the Protocol Configuration Options IE. 

3) After step 2, UE shall consider P-CSCF discovery procedure to be successful, and should initiate Registration for 

IMS services 

7.2 P-CSCF Discovery via DHCP - IPv4 
7.2.1 Definition 

Test to verify that UE will perform P-CSCF discovery procedure via DHCP. 
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7.2.2 Conformance requirement 

A. Prior to communication with the IM CN subsystem, the UE shall: 

a) perform a GPRS attach procedure; 

b) establish a PDP context used for SIP signalling according to the APN and GGSN selection criteria described in 
3GPP TS 23.060 and 3GPP TS 27.060 . This PDP context shall remain active throughout the period the UE is 
connected to the IM CN subsystem, i.e. from the initial registration and at least until the deregistration. As a 
result, the PDP context provides the UE with information that makes the UE able to construct an IPv6 address; 

c) acquire a P-CSCF address(es). 

The methods for P-CSCF discovery are: 

I. Employ Dynamic Host Configuration Protocol for IPv6 (DHCPv6) RFC 33 15 , the DHCPv6 options for SIP 
servers RFC 3319 and the DHCPv6 options for Domain Name Servers (DNS) RFC 3646 after PDP context 
activation. 

The UE shall either: 

in the DHCP query, request a list of SIP server domain names of P-CSCF(s) and the list of Domain Name 
Servers (DNS); or 

- request a list of SIP server IPv6 addresses of P-CSCF(s). 

The UE can freely select method I or II for P-CSCF discovery. In case method I is selected and several P-CSCF 
addresses or FQDNs are provided to the UE, the selection of P-CSCF address or FQDN shall be performed as 
indicated in RFC 3319 If sufficient information for P-CSCF address selection is not available, selection of the P- 
CSCF address by the UE is implementation specific. 

If the UE is designed to use I above, but receives P-CSCF address(es) according to II, then the UE shall either 
ignore the received address(es), or use the address(es) in accordance with II, and not proceed with the DHCP 
request according to I. 

The UE may request a DNS Server IPv6 address(es) via RFC 3315 or by the Protocol Configuration Options IE 
when activating a PDP context according to 3GPP TS 27.060 . 

From 23.981 [35] 

b) based on DHCP. Currently the specifications limit this to the IPv6 methods for DHCP. In order for this method 
to be used by an IPv4 UE, it needs to be identified how IPv4 DHCP is used to obtain the P-CSCF address. A 
solution that provides access independence would be that an IPv4 P-CSCF and IPv4 UE support configuration of 
the appropriate P-CSCF information via DHCPv4. In this solution, use of DHCP provides the UE with the fully 
qualified domain name of a P-CSCF and the address of a Domain Name Server (DNS) that is capable of 
resolving the P-CSCF name. When using DHCP/DNS procedure for P-CSCF discovery with IPv4 GPRS-access, 
the GGSN acts as DHCP Relay agent relaying DHCP messages between UE and the DHCP server. This is 
necessary to allow the UE to properly interoperate with the GGSN. This solution however requires that a UE 
supporting early IPv4 implementations would support DHCPv4. 

Reference(s) 

3GPP TS 24.229[10], clause 9.2.1 

3GPP TR 23.981 [35], clause 5.2.1. 



7.2.3 Test purpose 



To verify UE shall initiate and successfully complete a P-CSCF discovery procedure via DHCP when P-CSCF address 
is not provided as part of PDP Context Activation procedure. 
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7.2.4 Method of test 

Initial conditions 

The UE is in GMM-state "GMM-REGISTERED, normal service" with valid P-TMSI and CKSN. UE is not registered 
to IMS services. UE is not configured for using static P-CSCF address. UE has established a PDP context (No P-CSCF 
address information provided). ). If UE sets flag "DNS Server Address Request" in PCO of PDP Context Request, DNS 
server address list is provided in PDP Context Accept message. 

Related ICS/IXIT Statement(s) 
UE Supports IPv4 (Yes/No) 
UE capable of being configured to initiate P-CSCF Discovery via DHCPv4 (Yes/No) 

Test procedure 

1) If UE already knows DHCP server address, it goes to step 3. Otherwise, UE sends DHCPDISCOVER message 
locating a server. 

2) SS responds by DHCPOFFER message. 

3) UE sends DHCPINFORM message requesting for P-CSCF address(es) in options field. 

4) SS responds by DHCPACK message providing the domain names of P-CSCF address(es) and giving DNS 
server address. 

5) UE initiates a DNS NAPTR query to select the transport protocol. UE"s configured to use specific Transport 
protocol on default ports, can skip steps 5 to 8 and go directly to step 9. 

6) SS responds with NAPTR response. 

7) UE initiates a DNS SRV query. 

8) SS responds with SRV response. 

9) UE initiates a DNS A query 

10) SS responds with DNS A response. 

1 1) UE is made to initiate Registration procedure for IMS services. 
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Expected sequence 



Step 


Direction 


lUlessage 


Comment 


UE 1 SS 


1 


^ 


DHCPDISCOVER 


Optionally sent if UE does not have DHCP server 
address. 


2 


^ 


DHCPOFFER 


Sent if DHCP Discover message is received. 


3 


-> 


DHCPINFORM 


Requesting P-CSCF Address(es) 


4 


<r 


DHCPACK 


Including P-CSCF Address{es) 


5 


■^ 


DNS NAPTR Query 


UE configured to use specific Transport protocol on 
default ports, can skip steps 5 to 8 and go directly to 
step 9 


6 


^ 


DNS NAPTR Response 




7 


^ 


DNS SRV Query 




8 


4- 


DNS SRV Response 




9 


-> 


DNS A Query 




10 


^ 


DNS A Response 




11 


-^^ 


Registration 


UE is made to initiate Registration procedure to IMS 
services as defined in Annex C Generic 
Registration Procedure. 



Specific Message Contents: 

DHCPDISCOVER (step 1) 

Use the default message in annex B 

DHCPOFFER (step 2) 

Use the default message in annex B 

DHCPINFORM (Step 3) 

Use the default message in annex B with the following exeptions 



Field 


Value/Remarl<s 


Qptions 


* 


-code 


53 (DHCP IVIessage Type) 


- len 


1 


-Type 


2(DHCPQFFER) 


option-code 
- option-len 


55 (Parameter Request List) 

Set to number of values requested for configuration 

parameters 


Qption code 


120 (SIP Server Option) " 


Qption code 


6(Domain Server) Optionally present 



*Note 1 : Other options may also be present 

** Note 2:Other option codes may also be present and options can be in any order 
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DHCPACK (step 4) 

Use the default message in annex B.2 with the following exceptions 



Field 


Value/Remarks 


option-code 
- option-len 

-enc 


120 (SIP Server option) 

Length of encoded server domain address +1 (for enc 

field) 




Domain-address 1 


SS P-CSCF server domain AddressRFC 3361 [57] 


option-code 
- option-len 


6 ( DNS option RFC 2132[49]) )(lncluded only if 

requested in DHCP INFORM) 

4 


DNS Address 


4 byte IPv4 address of DNS server 



DNS NAPTR Query (step 5) 



Field 


Value/Remarks 


OPCODE= 


SQUERY 


QNAME= 


P-CSCF domain name received 


QCLASS= 


IN 


QTYPE= 


NAPTR 



DNS NAPTR Response (step 6) 



Field 


Value/Remarks 


OPCODE= 


SQUERY, RESPONSE, AA 


QNAME= 


Same as received in NAPTR Ouery 


QCLASS= 


IN 


QTYPE= 


NAPTR 


NAPTR Records 


NAPTR Records included for each Transport protocol 
(TLS, TCP, UDP) supported RFC 3263[50] 



DNS SRV Query (step 7) 



Field 


Value/Remarks 


OPCODE= 


SQUERY 


QNAME= 


Corresponding to the transport protocol selected by UE 
among those provided in DNS NAPTR Response 


QCLASS= 


IN 


QTYPE= 


SRV 



DNS SRV Response (step 8) 



Field 


Value/Remarks 


QPCODE= 


SQUERY, RESPONSE, AA 


QNAME= 


Same as received in SRV Query 


QCLASS= 


IN 


QTYPE= 


NAPTR 


SRV Records 


SRV Resource Record included providing the SS target 
server FQDN RFC 3263[50]. 
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Field 


Value/Remarks 


OPCODE= 


SQUERY 


QNAME= 


Selected P-CSCF name among provided in step 8 based 
on priority and weight RFC 2728[56] 


QCLASS= 


IN 


QTYPE= 


A 



Case 2: steps 5 to 8 not executed: 



Field 


Value/Remarks 


OPCODE= 


SQUERY 


QNAME= 


Selected P-CSCF name among addresses provided in 
step 4. 


QCLASS= 


IN 


QTYPE= 


A 



DNS A Response (step 10) 



IE 


Value/Remarks 


OPCODE= 


SQUERY, RESPQNSE, AA 


QNAME= 


Same as received in SRV Query 


QCLASS= 


IN 


QTYPE= 


A 


A or AAAA records 


Includes resolved IP address(es). 



7.2.5 Test requirements 

1) In step 3, UE shall initiate a P-CSCF discovery employing DHCP. 

2) After step 4, UE shall initiate a DNS query for domain address to IPv4 address translation. 

3) After step 10, UE should have resolved P-CSCF IPv4 address and should initiate Registration procedure to IMS 
services. 

7.3 P-CSCF Discovery via DHCP - IPv4 (UE Requests P- 
CSCF discovery via PCO) 

7.3.1 Definition 

Test to verify that on not receiving P-CSCF Address(es) in PCO, UE will perform P-CSCF discovery procedure 
employing DHCP. 

7.3.2 Conformance requirement 

Prior to communication with the IM CN subsystem, the UE shall: 

a) perform a GPRS attach procedure; 

b) establish a PDP context used for SIP signalling according to the APN and GGSN selection criteria described in 
3GPP TS 23.060 and 3GPP TS 27.060 . This PDP context shall remain active throughout the period the UE is 
connected to the IM CN subsystem, i.e. from the initial registration and at least until the deregistration. As a 
result, the PDP context provides the UE with information that makes the UE able to construct an IPv6 address; 
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c) acquire a P-CSCF address(es). 

The methods for P-CSCF discovery are: 

I. Employ Dynamic Host Configuration Protocol for IPv6 (DHCPv6) RFC 3315, the DHCPv6 options for SIP 
servers RFC 3319 and the DHCPv6 options for Domain Name Servers (DNS) RFC 3646 after PDP context 
activation. 

The UE shall either: 

in the DHCP query, request a list of SIP server domain names of P-CSCF(s) and the list of Domain Name 
Servers (DNS); or 

- request a list of SIP server IPv6 addresses of P-CSCF(s). 

II. Transfer P-CSCF address(es) within the PDP context activation procedure. 

The UE shall indicate the request for a P-CSCF address to the GGSN within the Protocol Configuration 
Options IE of the ACTIVATE PDP CONTEXT REQUEST message or ACTIVATE SECONDARY PDP 
CONTEXT REQUEST message. 

If the GGSN provides the UE with a list of P-CSCF IPv6 addresses in the ACTIVATE PDP CONTEXT 
ACCEPT message or ACTIVATE SECONDARY PDP CONTEXT ACCEPT message, the UE shall assume 
that the list is prioritised with the first address within the Protocol Configuration Options IE as the P-CSCF 
address with the highest priority. 

The UE can freely select method I or II for P-CSCF discovery. In case method I is selected and several P-CSCF 
addresses are provided to the UE, the selection of P-CSCF address or FQDNs shall be performed as indicated in 
RFC 33 19 . If sufficient information for P-CSCF address selection is not available, selection of the P-CSCF 
address by the UE is implementation specific. 

If the UE is designed to use I above, but receives P-CSCF address(es) according to II, then the UE shall either 
ignore the received address(es), or use the address(es) in accordance with II, and not proceed with the DHCP 
request according to I. 

The UE may request a DNS Server IPv6 address(es) via RFC 3315 or by the Protocol Configuration Options IE 
when activating a PDP context according to 3GPP TS 27.060 . 

From 23.981 [35] 

b) based on DHCP. Currently the specifications limit this to the IPv6 methods for DHCP. In order for this method 
to be used by an IPv4 UE, it needs to be identified how IPv4 DHCP is used to obtain the P-CSCF address. A 
solution that provides access independence would be that an IPv4 P-CSCF and IPv4 UE support configuration of 
the appropriate P-CSCF information via DHCPv4. In this solution, use of DHCP provides the UE with the fully 
qualified domain name of a P-CSCF and the address of a Domain Name Server (DNS) that is capable of 
resolving the P-CSCF name. When using DHCP/DNS procedure for P-CSCF discovery with IPv4 GPRS-access, 
the GGSN acts as DHCP Relay agent relaying DHCP messages between UE and the DHCP server. This is 
necessary to allow the UE to properly interoperate with the GGSN. This solution however requires that a UE 
supporting early IPv4 implementations would support DHCPv4. 

Reference(s) 

3GPP TS 24.229[10], clause 9.2.1 

3GPP TR 23.981 [35], clause 5.2.1. 



7.3.3 Test purpose 



To verify that the UE sends a correctly composed Activate PDP context request message requesting for P-CSCF 
address(es) to the GGSN within the Protocol Configuration Options IE. 

On receiving Activate PDP Context accept not including P-CSCF address(es) in PCO, UE will initiate a P-CSCF 
discovery procedure employing DHCP/DNS. 
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7.3.4 Method of test 

Initial conditions 

The UE is in GMM-state "GMM-REGISTERED, normal service" with valid P-TMSI and CKSN. UE is not registered 
to IMS services, has not established PDP context. UE is not configured for using static P-CSCF address. 

Related ICS/IXIT Statement(s) 
UE Supports IPv4 (Yes/No) 
UE capable of being configured to initiate P-CSCF Discovery via PCO (Yes/No) 

UE supports P-CSCF Discovery via PCO and DHCPv4(Yes/No)Test procedure 

1) UE is configured for requesting P-CSCF address(es) in Protocol Configuration Options IE in Activate PDP 
Context Request message. UE initiates an Activate PDP Context procedure. 

2) SS Responds with an Activate PDP Context Accept message by not including P-CSCF Address(es). If a UE 
already knows DHCP server address, it goes to step 5. If UE sets flag "DNS Server Address Request" in PCO of 
PDP Context Request, DNS server address list is provided in PDP context Accept message. 

3) If UE already knows DHCP server address, it goes to step 5. Otherwise, UE sends DHCPDISCOVER message 
locating a server. 

4) SS responds by DHCPOFFER message. 

5) UE sends DHCPINFORM message requesting for P-CSCF address(es) in options field. 

6) SS responds by DHCPACK message providing the domain names of P-CSCF address(es) and giving a DNS 
server address. 

7) UE initiates a DNS NAPTR query to select the transport protocol. UE"s configured to use specific Transport 
protocol on default ports, can skip steps 7 to 10 and go directly to step 11. 

8) SS responds with NAPTR response. 

9) UE initiates a DNS SRV query. 

10) SS responds with SRV response. 

11) UE initiates a DNS A or query 

12) SS responds with DNS A or response 
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Expected sequence 



Step 


Direction 


Message 


Comment 


UE 1 SS 


1 


^ 


Activate PDP Context Request 


UE sends tliis PDU by setting request for P-CSCF 
address{es) to the GGSN witliin the Protocol 
Configuration Options IE 


2 


<- 


Activate PDP Context Accept 


SS Sends this response by not including P-CSCF 
address{es). ). If UE sets flag "DNS Server Address 
Request" in PCO of PDP Context Request, DNS 
server address list is provided in PDP context 
Accept message .IF UE knows DHCP server 
address, it goes to step 5. 


3 


^ 


DHCPDISCOVER 


Optionally sent if UE does not have DHCP server 
address. 


4 


-^ 


DHCPOFFER 


Sent if DHCP Discover message is received. 


5 


-^ 


DHCPINFORM 


Requesting P-CSCF Address(es) 


6 


-f- 


DHCPACK 


Including P-CSCF Address(es) 


7 


^ 


DNS NAPTR Query 


UE"s configured to use specific Transport protocol 
on default ports, can skip steps 7 to 10 and go 
directly to step 1 1 


8 


^ 


DNS NAPTR Response 




9 


-^ 


DNS SRV Query 




10 


^ 


DNS SRV Response 




11 


•^ 


DNS A or AAAA Query 




12 


-^ 


DNS A or AAAA Response 




13 


-^^ 


Registration 


UE is made to initiate Registration procedure to IMS 
services as defined in Annex C Generic 
Registration Procedure. 



Specific Message Contents: 

Activate PDP Context Request (step 1) 



IE 


Value/Remarl<s 


Protocol Configuration options 

- Additional Parameters 

- container 1 Identifier 

- Container 1 Length 


0001 H (P-CSCF Address Request) 
bytes 



Activate PDP Context Accept (step 2) 



IE 


Value/Remarks 


Protocol Configuration options 
- Additional Parameters 


Present only if "DNS Server Address Request" received 
in Request message 


- container 1 Identifier 

- Container 1 Length 

- Container 1 contents 


0003H (DNS Address) 

1 6 bytes 

IPV4 address of SS DNS server encoded as per 3GPP 




TR 23.981 [35] 



DHCPDISCOVER (step 3) 

Use the default message in annex B. 

DHCPOFFER (step 4) 

Use the default message in annex B. 
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DHCPINFORM (step 5) 

Use the default message in annex B with the following exceptions: 



Field 


Value/Remarks 


Options 

- code 

- len 
-Type 


* 

53 (DHCP IVIessage Type) 

1 

2 (DHCP OFFER) 


option-code 
- option-len 


55 (Parameter Request List) 

Set to number of values requested for configuration 

parameters 


Option code 


120 (SIP Server Option)" 


Option code 


6(Domain Server) Optionally present 



*Note 1 : Other options may also be present. 

** Note 2: Other option codes may also be present and options can be in any order. 

DHCPACK (step 6) 

Use the default message in annex B with the following exceptions: 



Field 


Value/Remarks 


option-code 
- option-len 

-enc 


120 (SIP Server option) 

Length of encoded server domain address +1 (for enc 

field) 




Domain-address 1 


SS P-CSCF server domain AddressRFC 3361 [57] 


option-code 
- option-len 


6 ( DNS option RFC 2132[49]) (Included only if requested 

in DHCP INFORM) 

4 


DNS Address 


4 byte IPv4 address of DNS server 



DNS NAPTR Query (step 7) 



Field 


Value/Remarks 


OPCODE= 


SOUERY 


ONAME= 


P-CSCF domain name received 


OCLASS= 


IN 


OTYPE= 


NAPTR 



DNS NAPTR Response (step 8) 



Field 


Value/Remarks 


OPCODE= 


SOUERY, RESPONSE, AA 


ONAME= 


Same as received in NAPTR Query 


OCLASS= 


IN 


OTYPE= 


NAPTR 


NAPTR Records 


NAPTR Records included for each Transport protocol 
(TLS, TCP, UDP) supported RFC 3263[50] 



DNS SRV Query (step 9) 



Field 


Value/Remarks 


OPCODE= 


SOUERY 


ONAME= 


Corresponding to the transport protocol selected by UE 
among those provided in DNS NAPTR Response 


OCLASS= 


IN 


OTYPE= 


SRV 
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DNS SRV Response (step 10) 



Field 


Value/Remarks 


OPCODE= 


SQUERY, RESPONSE, AA 


QNAME= 


Same as received in SRV Query 


QCLASS= 


IN 


QTYPE= 


NAPTR 


SRV Records 


SRV Resource Record included providing the SS target 
server FQDN RFC 3263[50]. 



DNS A Query (step 11) 

Case 1 : steps 7 to 1 executed: 



Field 


Value/Remarks 


OPCODE= 


SQUERY 


QNAME= 


Selected P-CSCF name among provided in step 8 based 
on priority and weight RFC 2728[56] 


QCLASS= 


IN 


QTYPE= 


A 



Case 2: steps 7 to 1 not executed: 



Field 


Value/Remarks 


QPCQDE= 


SQUERY 


QNAME= 


Selected P-CSCF name among addresses provided in 
step 6. 


QCLASS= 


IN 


QTYPE= 


A 



DNS A Response (step 12) 



Field 


Value/Remarks 


QPCQDE= 


SQUERY, RESPONSE, AA 


QNAME= 


Same as received in SRV Query 


QCLASS= 


IN 


QTYPE= 


A 


A records 


Includes resolved IP address(es). 



7.3.5 Test requirements 



1) In step 1, UE sets the IM CN Subsystem Signalling Flag to the GGSN within the Protocol Configuration Options 
IE. 

2) After step 2, UE shall initiate a P-CSCF discovery employing DHCP. 

3) In step 3, if UE has no knowledge of DHCP server address sends Discover message. 

4) In step 5, UE shall send DHCPRequest message, including options filed with option code 120. 

5) After step 6, UE shall initiate DNS query. 

6) After step 12, UE should have resolved P-CSCF IPv4 address and should initiate Registration procedure to IMS 

services. 
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7.4 P-CSCF Discovery by DHCP - IPv6 

7.4.1 Definition 

Test to verify that UE will perform P-CSCF discovery procedure employing DHCP. 

7.4.2 Conformance requirement 

Prior to communication with the IM CN subsystem, the UE shall: 

a) perform a GPRS attach procedure; 

b) establish a PDP context used for SIP signalling according to the APN and GGSN selection criteria described in 
3GPP TS 23.060 and 3GPP TS 27.060 This PDP context shall remain active throughout the period the UE is 
connected to the IM CN subsystem, i.e. from the initial registration and at least until the deregistration. As a 
result, the PDP context provides the UE with information that makes the UE able to construct an IPv6 address; 

c) acquire a P-CSCF address(es). 

The methods for P-CSCF discovery are: 

I. Employ Dynamic Host Configuration Protocol for IPv6 (DHCPv6) RFC 3315, the DHCPv6 options for SIP 
servers RFC 3319 and the DHCPv6 options for Domain Name Servers (DNS) RFC 3646 after PDP context 
activation. 

The UE shall either: 

in the DHCP query, request a list of SIP server domain names of P-CSCF(s) and the list of Domain Name 
Servers (DNS); or 

- request a list of SIP server IPv6 addresses of P-CSCF(s). 

II. Transfer P-CSCF address(es) within the PDP context activation procedure. 

The UE shall indicate the request for a P-CSCF address to the GGSN within the Protocol Configuration 
Options IE of the ACTIVATE PDP CONTEXT REQUEST message or ACTIVATE SECONDARY PDP 
CONTEXT REQUEST message. 

If the GGSN provides the UE with a list of P-CSCF IPv6 addresses in the ACTIVATE PDP CONTEXT 
ACCEPT message or ACTIVATE SECONDARY PDP CONTEXT ACCEPT message, the UE shall assume 
that the list is prioritised with the first address within the Protocol Configuration Options IE as the P-CSCF 
address with the highest priority. 

The UE can freely select method I or II for P-CSCF discovery. In case method I is selected and several P-CSCF 
addresses or FQDNs are provided to the UE, the selection of P-CSCF address or FQDN shall be performed as 
indicated in RFC 3319. If sufficient information for P-CSCF address selection is not available, selection of the P- 
CSCF address by the UE is implementation specific. 

If the UE is designed to use I above, but receives P-CSCF address(es) according to II, then the UE shall either 
ignore the received address(es), or use the address(es) in accordance with II, and not proceed with the DHCP 
request according to I. 

The UE may request a DNS Server IPv6 address(es) via RFC 3315 and RFC 3646 or by the Protocol 
Configuration Options IE when activating a PDP context according to 3GPP TS 27.060 . 

Reference(s) 

3G TS 24.229[10], clause 9.2.1 
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7.4.3 Test purpose 

UE will initiate P-CSCF discovery procedure employing DHCP. 

7.4.4 Method of test 

Initial conditions 

The UE is in GMM-state "GMM-REGISTERED, normal service" with valid P-TMSI and CKSN. UE is not registered 
to IMS services. UE has established a PDP context. UE has not received P-CSCF address(es) during PDP context 
estabHshment. If UE sets flag "DNS Server Address Request" in PCO of PDP Context Request, DNS server address list 
is provided in PDP Context Accept message. 

Related ICS/IXIT Statement(s) 
UE Supports IPv6 (Yes/No) 
UE capable of being configured to initiate P-CSCF Discovery via DHCPv6 (Yes/No) 

Test procedure 

1 . UE sends DHCP SOLICIT message locating a server. 

2. SS responds with DHCP ADVERTISE message. If UE requested for domain names or both domain names and 
IP address(es), SS will include P-CSCF server domain names. If UE requested for IP address only, SS includes 
IP address(es) of P-CSCF servers. If UE Requested for DNS Server Address, it is provided. If P-CSCF IP 
addresses are included go to step 1 1 , else go to step 5 

3. UE sends DHCP Query requesting either IP address(es) of P-CSCF server(s) or domain names of P-CSCF 
server(s) and DNS Server. 

4. SS responds by DHCP Reply message. If UE requested for domain names or both domain names and IP 
address(es), SS will include P-CSCF server domain names. If UE requested for IP address only, SS includes IP 
address(es) of P-CSCF servers. If UE Requested for DNS Server Address, it is provided. If P-CSCF IP 
addresses are included go to step 1 1 . 

5. UE initiates a DNS NAPTR query to select the transport protocol. UE"s configured to use specific Transport 
protocol on default ports, can skip steps 5 to 8 and go directly to step 1 1 . 

6. SS responds with NAPTR response. 

7. UE initiates a DNS SRV query. 

8. SS responds with SRV response. 

9. UE initiates a DNS AAAA query 

10. SS responds with DNS AAAA response. 

1 1 . UE is made to initiate Registration procedure for IMS services. 



£75/ 



3GPP TS 34.229-1 version 5.0.0 Release 5 



33 



ETSI TS 134 229-1 V5.0.0 (2006-06) 



Expected sequence 



Step 


Direction 


lUlessage 


Comment 


UE 1 SS 


1 


^ 


DHCP SOLICIT 




2 


-^ 


DHCP ADVERTISE 


Sent if DHCP Solicit message is received. 
Including P-CSCF Address(es). 
If P-CSCF IP addresses are included go to step 1 1 , 
else go to step 5 


3 


-> 


DHCP Information-Request 


Requesting P-CSCF Address(es)* 


4 


-^ 


DHCP Reply 


Including P-CSCF Address{es). 

If P-CSCF IP addresses are included go to step 1 1 . 


5 


^ 


DNS NAPTR Query 


UE"s configured to use specific Transport protocol 
on default ports, can skip steps 5 to 8 and go 
directly to step 9 


6 


-^ 


DNS NAPTR Response 




7 


-^ 


DNS SRV Query 




8 


-^ 


DNS SRV Response 




9 


^ 


DNS AAAA Query 




10 


^ 


DNS AAAA Response 




11 


-^^ 


Registration 


UE is made to initiate Registration procedure to IIVIS 
services as defined in Annex A. 2 Generic 
Registration Procedure. 



* Note: UE may request all options in one Information Request or send multiple Information Requests. If UE opts 
for multiple Information Request transmissions, SS transmits accordingly multiple Reply messages 
including corresponding requested options. 

Specific Message Contents: 

Step 1: DHCP SOLICIT* 

Use the default message in annex B. 1 with the following exceptions 



Options 


Value/Remarks 


option-code 


OPTION_ORO (6) 


- option-len 


2 times number of requested options 


-requested-option-code-1 


OPTION SIP SERVER D(21)0R 
OPTION_SIP_SERVER_A (22) 


- requested-option-code-2 


OPTION_DNS_SERVERS (23) 


- requested-option-code-3 


OPTION DOMAIN LIST (24) 



*Note: Options can be optionally present and option codes can be in any order 

**Note: Numerical value, "(n)", provided in brackets in Column Value/Remarks is the 'octal' value for this option. 

Step 2: DHCP ADVERTISE 

Use the default message in annex B.l with the following exceptions 

Note: Options are included only if corresponding Requests are received. 
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Case 1: OPTION_SIP_SERVER_D (21) ) or both (OPTION_SIP_SERVER_D (21) and 

OPTION_SIP_SERVER_A (22)) and OPTION_DOMAIN_LIST(24) or 
OPTION_DNS_SERVERS (23) received in step 1 





Options 


Value/Remarks 


option-code 
- option-len 


OPTION_SIP_SERVER_D (21) 

Length of encoded domain address RFC 3319[51] 


Domain-address 1 




SS P-CSCF server domain address RFC 331 9[51 ] 



option-code 
- option-len 
Domain-address 1 



OPTION_DNS_SERVERS (23) 

Length of encoded DNS server address RFC 3646[48] 

SS DNS server IPv6 address RFC 3646[48] 



option-code 
- option-len 
searchlist 



OPTION_DOMAIN_LIST (24) 

Length of Domain search list 

List of Domain Names encoded as per RFC 1035[52] 



*Note: Numerical value, "(n)", provided in brackets in Column Value/Remarks is the 'octal' value for this option. 



Case 2: OPTION_SIP_SERVER_A (22) received in step 1 



Options 



Value/Remarks 



option-code 
- option-len 
Domain-address 1 



Domain-address 1 



OPTION_SIP_SERVER_A (22) 

128 

IPv6 address of SS P-CSCF Server 



option-code 
- option-len 


OPTION_DNS_SERVERS (23) 

Length of encoded DNS server address RFC 3646[48] 



SS DNS server IPv6 address RFC 3646[48] 



option-code 
- option-len 
searchlist 



OPTION_DOMAIN_LIST (24) 

Length of Domain search list 

List of Domain Names encoded as per RFC 1035[52] 



*Note: Numerical value, "(n)", provided in brackets in Column Value/Remarks is the 'octal' value for this option. 

Step 3: DHCP Information-Request 

Use the default message in annex B. 1 with the following exceptions 

Options Value/Remarks 



option-code 

- option-len 

- requested-option-code-1 

- requested-option-code-2 

- requested-option-code-3 



OPTION_ORO (6) 

2 * number of requested options 

OPTION_SIP_SERVER_D (21) OR 
OPTION_SIP_SERVER_A (22) 

OPTION_DNS_SERVERS(23)(Optional) 

OPTION_DOMAIN_LIST (24) (Optional) 



Note: All options can be either received in one message or multiple messages. If more than one option codes 
present they can be in any order. 

**Note: Numerical value, "(n)", provided in brackets in Column Value/Remarks is the 'octal' value for this option. 
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Step 4: DHCP Reply 

Use the default message in annex B. 1 with the following exceptions 

Note: Options are included only if corresponding Requests are received. 

Case 1 : OPTION_SIP_SERVER_D (21) ) or both (OPTION_SIP_SERVER_D (21) and 

OPTION_SIP_SERVER_A (22)) and OPTION_DOMAIN_LIST(24) or 
OPTION_DNS_SERVERS (23) received in step 3 



Options 



Value/Remarks 



option-code 
- option-len 
Domain-address 1 



OPTION_SIP_SERVER_D (21) 

Length of encoded domain address RFC 3319[51] 

SS P-CSCF server domain Address RFC 3319[51] 



option-code 
- option-len 
Domain-address 1 



OPTION_DNS_SERVERS (23) 

Length of encoded DNS server address RFC 3646[48] 

SS DNS server IPv6 address RFC 3646[48] 



option-code 
- option-len 
searchlist 



OPTION_DOMAIN_LIST (24) 

Length of Domain search list 

List of Domain Names encoded as per RFC 1035[52] 



*Note: Numerical value, "(n)", provided in brackets in Column Value/Remarks is the 'octal' value for this option. 



Case 2: OPTION_SIP_SERVER_A (22) received in step 3 



Options 



Value/Remarks 



option-code 
- option-len 
Domain-address 1 



OPTION_SIP_SERVER_A (22) 

128 

IPv6 address of SS P-CSCF Server 



option-code 
- option-len 
Domain-address 1 



OPTION_DNS_SERVERS (23) 

Length of encoded DNS server address RFC 3646[48] 

SS DNS server IPv6 address RFC 3646[48] 



option-code 
- option-len 
searchlist 



OPTION_DOMAIN_LIST (24) 

Length of Domain search list 

List of Domain Names encoded as per RFC 1035 [52] 



*Note: Numerical value, "(n)", provided in brackets in Column Value/Remarks is the 'octal' value for this option. 
Step 5: DNS NAPTR Query 



OPCODE^ 
QNAME= 
QCLASS= 
QTYPE= 



Field 



Value/Remarks 

SQUERY 

P-CSCF domain name received 

IN 

NAPTR 
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Step 6: DNS NAPTR Response 

Field 

OPCODE= 
QNAME= 
QCLASS= 
QTYPE= 
NAPTR Records 



Value/Remarks 

SQUERY, RESPONSE, AA 

Same as received in NAPTR Query 

IN 

NAPTR 

NAPTR Records included for each Transport protocol 
(TLS, TCP, UDP) supported RFC 3263[50] 



Step 7: DNS SRV Query 



Field 



OPCODE= 
QNAME= 

QCLASS= 
QTYPE= 



Value/Remarks 



SQUERY 



Corresponding to the transport protocol selected by UE 
among those provided in DNS NAPTR Response 

IN 

SRV 



Step 8: DNS SRV Response 

Field 

QPCODE= 
QNAME= 
QCLASS= 
QTYPE= 
SRV Records 



Value/Remarks 

SQUERY, RESPONSE, AA 

Same as received in SRV Query 

IN 

NAPTR 

SRV Resource Record included providing the SS target 
server FQDN RFC 3263[50]. 



Step 9: DNS AAAA Query 
Case 1 : steps 5 to 8 executed: 

Field 

QPCQDE= 
QNAIVIE= 

QCLASS= 
QTYPE= 



Value/Remarks 



SQUERY 



Selected P-CSCF name among provided in step 8 based 
on priority and weight RFC 2728[56] 

IN 

AAAA 



Case 2: steps 5 to 8 not executed: 

Field 

QPCQDE= 
QNAME= 

QCLASS= 
QTYPE= 



Value/Remarks 



SQUERY 



Selected P-CSCF name among addresses provided in 
step 2 or 4. 

IN 

AAAA 
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Step 10: DNS AAAA Response 

Field 

OPCODE= 
QNAME= 
QCLASS= 
QTYPE= 
AAAA records 



Value/Remarks 

SQUERY, RESPONSE, AA 

Same as received in AAAA Query 

IN 

AAAA 

Includes resolved IP address(es). 



7.4.5 Test requirements 

1. In step 1, UE shall initiate a P-CSCF discovery employing DHCP. 

2. After step 2 and 4, if P-CSCF IPv6 address is received UE will consider P-CSCF discovery procedure 
successful, else will initiate a DNS query for domain address to IPv6 address translation. 

3. After step 10, UE will consider P-CSCF discovery procedure to be successful and should initiate Registration 
procedure to IMS services. 

7.5 P-CSCF Discovery by DHCP-IPv6 (UE Requests P-CSCF 
discovery by PCO) 

7.5.1 Definition 

Test to verify that on not receiving P-CSCF Address(es) in PCO, will perform P-CSCF discovery procedure employing 
DHCP. 

7.5.2 Conformance requirement 

Prior to communication with the IM CN subsystem, the UE shall: 

a) perform a GPRS attach procedure; 

b) establish a PDP context used for SIP signalling according to the APN and GGSN selection criteria described in 
3GPP TS 23.060 and 3GPP TS 27.060. This PDP context shall remain active throughout the period the UE is 
connected to the IM CN subsystem, i.e. from the initial registration and at least until the deregistration. As a 
result, the PDP context provides the UE with information that makes the UE able to construct an IPv6 address; 



c) acquire a P-CSCF address(es). 

The methods for P-CSCF discovery are: 

I. Employ Dynamic Host Configuration Protocol for IPv6 (DHCPv6) RFC 3315, the DHCPv6 options for SIP 
servers RFC 3319 and the DHCPv6 options for Domain Name Servers (DNS) RFC 3646 after PDP context 
activation. 

The UE shall either: 

in the DHCP query, request a list of SIP server domain names of P-CSCF(s) and the list of Domain Name 
Servers (DNS); or 

- request a list of SIP server IPv6 addresses of P-CSCF(s). 

II. Transfer P-CSCF address(es) within the PDP context activation procedure. 
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The UE shall indicate the request for a P-CSCF address to the GGSN within the Protocol Configuration 
Options IE of the ACTIVATE PDF CONTEXT REQUEST message or ACTIVATE SECONDARY PDP 
CONTEXT REQUEST message. 

If the GGSN provides the UE with a list of P-CSCF IPv6 addresses in the ACTIVATE PDP CONTEXT 
ACCEPT message or ACTIVATE SECONDARY PDP CONTEXT ACCEPT message, the UE shall assume 
that the list is prioritised with the first address within the Protocol Configuration Options IE as the P-CSCF 
address with the highest priority. 

The UE can freely select method I or II for P-CSCF discovery. In case method I is selected and several P-CSCF 
addresses or FQDNs are provided to the UE, the selection of P-CSCF address or FQDN shall be performed as 
indicated in RFC 3319 [41]. If sufficient information for P-CSCF address selection is not available, selection of 
the P-CSCF address by the UE is implementation specific. 

If the UE is designed to use I above, but receives P-CSCF address(es) according to II, then the UE shall either 
ignore the received address(es), or use the address(es) in accordance with II, and not proceed with the DHCP 
request according to I. 

The UE may request a DNS Server IPv6 address(es) via RFC 3315 and RFC 3646 or by the Protocol 
Configuration Options IE when activating a PDP context according to 3GPP TS 27.060. 

Reference(s) 

3G TS 24.229[10], clause 9.2.1 

7.5.3 Test purpose 

To verify that the UE sends a correctly composed Activate PDP context requesting for P-CSCF address(es) to the 
GGSN within the Protocol Configuration Options IE. 

On receiving Activate PDP Context accept not including P-CSCF address(es) in PCO IE, will initiate a P-CSCF 
discovery procedure employing DHCP. 

7.5.4 Method of test 

Initial conditions 

The UE is in GMM-state "GMM-REGISTERED, normal service" with valid P-TMSI and CKSN. UE is not registered 
to IMS services, has not established PDP context. 

Related ICS/IXIT Statement(s) 
UE Supports IPv6 (Yes/No) 

UE capable of being configured to initiate P-CSCF Discovery via PCO (Yes/No) 
UE supports P-CSCF Discovery via PCO and DHCPv6(Yes/No) 

Test procedure 

1 . UE is configured for requesting P-CSCF address(es) in Protocol Configuration Options IE in Activate PDP 
Context Request message. UE initiates an Activate PDP Context procedure. 

2. SS Responds with an Activate PDP Context Accept message by not including P-CSCF address(es). If UE sets 
flag "DNS Server Address Request" in PCO of PDP Context Request, DNS server address list is provided in 
PDP Context Accept message. 

3. UE sends Solicit message locating a server. 

4. SS responds by Advertise message. If UE requested for domain names or both domain names and IP address(es), 
SS will include P-CSCF server domain names. If UE requested for IP address only, SS includes IP address(es) of 
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P-CSCF servers. If UE Requested for DNS Server Address, it is provided. If P-CSCF IP addresses are included 
go to step 13 else go to step 7. 

5. UE sends DHCP Information-Request Query requesting either IP address(es) of P-CSCF server(s) or domain 
names of P-CSCF server(s) and DNS Server. 

6. SS responds by DHCP Reply message. . If UE requested for domain names or both domain names and IP 
address(es), SS will include P-CSCF server domain names. If UE requested for IP address only, SS includes IP 
address(es) of P-CSCF servers. If UE Requested for DNS Server Address, it is provided. If P-CSCF IP addresses 
are included go to step 13. 

7. UE initiates a DNS NAPTR query to select the transport protocol. UE"s configured to use specific Transport 
protocol on default ports, can skip steps 7 to 10 and go directly to step 11. 

8. SS responds with NAPTR response. 

9. UE initiates a DNS SRV query. 

10. SS responds with SRV response. 

1 1 . UE initiates a DNS AAAA query 

12. SS responds with DNS AAAA response 

13. UE is made to initiate Registration procedure for IMS services. 

Expected sequence 



Step 


Direction 


lUlessage 


Comment 


UE 1 SS 


1 


^ 


Activate PDP Context Request 


UE sends this PDU by setting request for P-CSCF 
address{es) to the GGSN within the Protocol 
Configuration Options IE 


2 


<- 


Activate PDP Context Accept 


SS Sends this response by not including P-CSCF 
address{es). If UE sets flag "DNS Server Address 
Request" in PCO of PDP Context Request, DNS 
server address list is provided. 


3 


-> 


DHCP SOLICIT 




4 


^ 


DHCP ADVERTISE 


Sent if DHCP Solicit message is received. 
Including P-CSCF Address(es). If P-CSCF IP 
addresses are included go to step 13 else go to 
step? 


5 


^ 


DHCP Information-Request 


Requesting P-CSCF Address(es)* 


6 


<- 


DHCP Reply 


Including P-CSCF Address(es). If P-CSCF IP 
addresses are included go to step 13. 


7 


^ 


DNS NAPTR Query 


UE"s configured to use specific Transport protocol 
on default ports, can skip steps 7 to 10 and go 
directly to step 1 1 


8 


<- 


DNS NAPTR Response 




9 


■^ 


DNS SRV Query 




10 


<- 


DNS SRV Response 




11 


-> 


DNS AAAA Query 




12 


<- 


DNS AAAA Response 




13 


^^ 


Registration 


UE is made to initiate Registration procedure to IMS 
services as defined in Annex A. 2 Generic 
Registration Procedure. 



■ Note: UE may request all options in one Information Request or send multiple Information Requests. If UE opts 
for multiple Information Request transmissions, SS transmits accordingly multiple Reply messages 
including corresponding requested options. 
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Options 


Value/Remarks 


Protocol Configuration options 




- Additional Parameters 




- container 1 Identifier 


0001 H (P-CSCF Address Request) 


-- Container 1 Length 


bytes 


- container 2 Identifier 


0003H (DNS Server Address Request) (Optionally 
present) 


-- Container 2 Length 


bytes 



Step 2: Activate PDP Context Accept 



Options 


Value/Remarks 


Protocol Configuration options 

- Additional Parameters 

- container 1 Identifier 
-- Container 1 Length 
-- Container 1 contents 


(Included if "DNS Server Address Request" is received) 

0003H (DNS Address) 

1 6 bytes 

IPV6 address of SS DNS Server 



Step 3: DHCP SOLICIT* 

Use the default message in annex B. 1 with the following exceptions 



Options 


Value/Remarks 


option-code 


OPTION_ORO (6) 


- option-len 


2 times number of requested options 


- requested-option-code-1 


OPTION SIP SERVER D(21)0R 
OPTION_SIP_SERVER_A (22) 


- requested-option-code-2 


OPTION_DNS_SERVERS (23) 


- requested-option-code-3 


OPTION DOMAIN LIST (24) 



*Note: Options can be optionally present and option codes can be in any order 

**Note: Numerical value, "(n)", provided in brackets in Column Value/Remarks is the 'octal' value for this option. 

Step 4: DHCP ADVERTISE 

Use the default message in annex B.l with the following exceptions 

Note: Options are included only if corresponding Requests are received. 
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Case 1: OPTION_SIP_SERVER_D (21) or both (OPTION_SIP_SERVER_D (21) and 

OPTION_SIP_SERVER_A (22)) and OPTION_DOMAIN_LIST(24) or 
OPTION_DNS_SERVERS (23) received in step 3 



Options 



Value/Remarks 



option-code 
- option-len 
Domain-address 1 



OPTION_SIP_SERVER_D (21) 

Length of encoded domain address RFC 3319[51] 

SS P-CSCF server domain Address RFC 3319[51] 



option-code 
- option-len 
Domain-address 1 



OPTION_DNS_SERVERS (23) 

Length of encoded DNS server address RFC 3646[48] 

SS DNS server IPv6 address RFC 3646[48] 



option-code 
- option-len 



OPTION_DOMAIN_LIST (24) 
Length of Domain search list 



searchlist 



List of Domain Names encoded as per RFC 1035[52] 



*Note: Numerical value, "(n)", provided in brackets in Column Value/Remarks is the 'octal' value for this option. 



Case 2: OPTION_SIP_SERVER_A (22) received in step 3 



Options 



Value/Remarks 



option-code 
- option-len 
Domain-address 1 



OPTION_SIP_SERVER_A (22) 

128 

IPv6 address of SS P-CSCF Server 



option-code 
- option-len 
Domain-address 1 



OPTION_DNS_SERVERS (23) 

Length of encoded DNS server address RFC 3646[48] 

SS DNS server IPv6 address RFC 3646[48] 



option-code 
- option-len 
searchlist 



OPTION_DOMAIN_LIST (24) 

Length of Domain search list 

List of Domain Names encoded as per RFC 1035 [52] 



*Note: Numerical value, "(n)", provided in brackets in Column Value/Remarks is the 'octal' value for this option. 

Step 5: DHCP Information-Request 

Use the default message in annex B. 1 with the following exceptions 



Options 


Value/Remarks 


option-code 


OPTION_ORO (6) 


- option-len 


2 * number of requested options 


-requested-option-code-1 


OPTION SIP SERVER D(21)0R 
OPTION_SIP_SERVER_A (22) 


- requested-option-code-2 


OPTION_DNS_SERVERS(23)(Optional) 


- requested-option-code-3 


OPTION DOMAIN LIST (24) (Optional) 



Note: All options can be either received in one message or multiple messages. If more than one option codes 
present they can be in any order. 

**Note: Numerical value, "(n)", provided in brackets in Column Value/Remarks is the 'octal' value for this option. 
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Step 6: DHCP Reply 

Use the default message in annex B. 1 with the following exceptions 

Note: Options are included only if corresponding Requests are received. 

Case 1 : OPTION_SIP_SERVER_D (21) ) or both (OPTION_SIP_SERVER_D (21) and 

OPTION_SIP_SERVER_A (22)) and OPTION_DOMAIN_LIST(24) or 
OPTION_DNS_SERVERS (23) received in step 5 



Options 



Value/Remarks 



option-code 
- option-len 
Domain-address 1 



OPTION_SIP_SERVER_D (21) 

Length of encoded domain address RFC 3319[51] 

SS P-CSCF server domain Address RFC 3319[51] 



option-code 
- option-len 
Domain-address 1 



OPTION_DNS_SERVERS (23) 

Length of encoded DNS server address RFC 3646[48] 

SS DNS server IPv6 address RFC 3646[48] 



option-code 
- option-len 
searchlist 



OPTION_DOMAIN_LIST (24) 

Length of Domain search list 

List of Domain Names encoded as per RFC 1035[52] 



*Note: Numerical value, "(n)", provided in brackets in Column Value/Remarks is the 'octal' value for this option. 



Case 2: OPTION_SIP_SERVER_A (22) received in step 5 



Options 



Value/Remarks 



option-code 
- option-len 
Domain-address 1 



OPTION_SIP_SERVER_A (22) 

128 

IPv6 address of SS P-CSCF Server 



option-code 
- option-len 
Domain-address 1 



OPTION_DNS_SERVERS (23) 

Length of encoded DNS server address RFC 3646[48] 

SS DNS server IPv6 address RFC 3646[48] 



option-code 
- option-len 
searchlist 



OPTION_DOMAIN_LIST (24) 

Length of Domain search list 

List of Domain Names encoded as per RFC 1035 [52] 



*Note: Numerical value, "(n)", provided in brackets in Column Value/Remarks is the 'octal' value for this option. 
Step 7: DNS NAPTR Query 



OPCODE^ 
QNAME= 
QCLASS= 
QTYPE= 



Field 



Value/Remarks 

SQUERY 

P-CSCF domain name received 

IN 

NAPTR 
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Step 8: DNS NAPTR Response 

Field 

OPCODE= 
QNAME= 
QCLASS= 
QTYPE= 
NAPTR Records 



Value/Remarks 

SQUERY, RESPONSE, AA 

Same as received in NAPTR Query 

IN 

NAPTR 

NAPTR Records included for each Transport protocol 
(TLS, TCP, UDP) supported RFC 3263[50] 



Step 9: DNS SRV Query 



Field 



OPCODE= 
QNAME= 

QCLASS= 
QTYPE= 



Value/Remarks 



SQUERY 



Corresponding to the transport protocol selected by UE 
among those provided in DNS NAPTR Response 

IN 

SRV 



Step 10: DNS SRV Response 

Field 

QPCODE= 
QNAME= 
QCLASS= 
QTYPE= 
SRV Records 



Value/Remarks 

SQUERY, RESPONSE, AA 

Same as received in SRV Query 

IN 

NAPTR 

SRV Resource Record included providing the SS target 
server FQDN RFC 3263[50]. 



Step 1 1 : DNS AAAA Query 
Case 1 : steps 7 to 1 executed: 

Field 

QPCQDE= 
QNAIVIE= 

QCLASS= 
QTYPE= 



Value/Remarks 



SQUERY 



Selected P-CSCF name among provided in step 10 
based on priority and weight RFC 2728[56] 

IN 

AAAA 



Case 2: steps 7 to 1 not executed: 

Field 

QPCQDE= 
QNAME= 

QCLASS= 
QTYPE= 



Value/Remarks 



SQUERY 



Selected P-CSCF name among addresses provided in 
step 4 or 6. 

IN 

AAAA 
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Step 12: DNS AAAA Response 

Field 

OPCODE= 
QNAME= 
QCLASS= 
QTYPE= 
AAAA records 



Value/Remarks 

SQUERY, RESPONSE, AA 

Same as received in AAAA Query 

IN 

AAAA 

Includes resolved IP address(es). 



7.5.5 Test requirements 

1. In step 1, UE sets the IM CN Subsystem Signalling Flag to the GGSN within the Protocol Configuration Options 
IE. 

2. After step 2, UE shall initiate a P-CSCF discovery employing DHCP. 

3. After step 6, if P-CSCF IPv6 address is received UE will consider P-CSCF discovery procedure successful, else 
will initiate a DNS query for domain address to IPv6 address translation. 

4. After step 12, UE will consider P-CSCF discovery procedure to be successful and should initiate Registration 
procedure to IMS services. 

7.6 P-CSCF Discovery by DHCP - IPv6 (UE does riot Request 
P-CSCF discovery by PCO, SS includes P-CSCF 
Address(es) in PCO) 



7.6.1 



Definition 



Test to verify that on not receiving P-CSCF Address(es) in PCO, will perform P-CSCF discovery procedure employing 
DHCP. 

7.6.2 Conformance requirement 

Prior to communication with the IM CN subsystem, the UE shall: 

a) perform a GPRS attach procedure; 

b) establish a PDP context used for SIP signalling according to the APN and GGSN selection criteria described in 
3GPP TS 23.060 and 3GPP TS 27.060. This PDP context shall remain active throughout the period the UE is 
connected to the IM CN subsystem, i.e. from the initial registration and at least until the deregistration. As a 
result, the PDP context provides the UE with information that makes the UE able to construct an IPv6 address; 



c) acquire a P-CSCF address(es). 

The methods for P-CSCF discovery are: 

I. Employ Dynamic Host Configuration Protocol for IPv6 (DHCPv6) RFC 3315, the DHCPv6 options for SIP 
servers RFC 3319 and the DHCPv6 options for Domain Name Servers (DNS) RFC 3646 after PDP context 
activation. 

The UE shall either: 

in the DHCP query, request a list of SIP server domain names of P-CSCF(s) and the list of Domain Name 
Servers (DNS); or 

- request a list of SIP server IPv6 addresses of P-CSCF(s). 
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II. Transfer P-CSCF address(es) within the PDP context activation procedure. 

The UE shall indicate the request for a P-CSCF address to the GGSN within the Protocol Configuration 
Options IE of the ACTIVATE PDP CONTEXT REQUEST message or ACTIVATE SECONDARY PDP 
CONTEXT REQUEST message. 

If the GGSN provides the UE with a list of P-CSCF IPv6 addresses in the ACTIVATE PDP CONTEXT 
ACCEPT message or ACTIVATE SECONDARY PDP CONTEXT ACCEPT message, the UE shall assume 
that the list is prioritised with the first address within the Protocol Configuration Options IE as the P-CSCF 
address with the highest priority. 

The UE can freely select method I or II for P-CSCF discovery. In case method I is selected and several P-CSCF 
addresses or FQDNs are provided to the UE, the selection of P-CSCF address or FQDN shall be performed as 
indicated in RFC 3319 [41]. If sufficient information for P-CSCF address selection is not available, selection of 
the P-CSCF address by the UE is implementation specific. 

If the UE is designed to use I above, but receives P-CSCF address(es) according to II, then the UE shall either 
ignore the received address(es), or use the address(es) in accordance with II, and not proceed with the DHCP 
request according to I. 

The UE may request a DNS Server IPv6 address(es) via RFC 3315 and RFC 3646 or by the Protocol 
Configuration Options IE when activating a PDP context according to 3GPP TS 27.060. 

Reference(s) 

3G TS 24.229[10], clause 9.2.1 

7.6.3 Test purpose 

To verify that a UE, which has not requested for P-CSCF address in PDP context activate message, receives P-CSCF 
address, may accept the P-CSCF address or ignore it and hence initiate P-CSCF discovery by DHCP. 

7.6.4 Method of test 

Initial conditions 

The UE is in GMM-state "GMM-REGISTERED, normal service" with valid P-TMSI and CKSN. UE is not registered 
to IMS services, has not established PDP context. 

Related ICS/IXIT Statement(s) 
UE Supports IPv6 (Yes/No) 

UE capable of being configured to initiate P-CSCF Discovery via DHCPv6 (Yes/No) 
UE supports P-CSCF Discovery via PCO and DHCPv6(Yes/No) 

Test procedure 

1. UE is configured for not requesting P-CSCF addresses in PCO. 

2. SS Responds with an Activate PDP Context Accept message by including P-CSCF Address(es). UE can either 
assume P-CSCF procedure to be complete or neglect the P-CSCF address(es) in PDP context Accept. Test Ends 
if UE assumes P-CSCF procedure to be complete. 

3. UE sends Solicit message locating a server. 

4. SS responds by Advertise message. . If UE requested for domain names or both domain names and IP 
address(es), SS will include P-CSCF server domain names. If UE requested for IP address only, SS includes IP 
address(es) of P-CSCF servers. If UE Requested for DNS Server Address, it is provided. If P-CSCF IP 
addresses are included go to step 13, else go to step 7. 
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5. UE sends DHCP Information-Request Query requesting either IP address(es) of P-CSCF server(s) or domain 
names of P-CSCF server(s) and DNS Server. 

6. SS responds by DHCP Reply message. If UE requested for domain names or both domain names and IP 
address(es), SS will include P-CSCF server domain names. If UE requested for IP address only, SS includes IP 
address(es) of P-CSCF servers. If UE Requested for DNS Server Address, it is provided. If P-CSCF IP 
addresses are included go to step 13. 

7. UE initiates a DNS NAPTR query to select the transport protocol. UE"s configured to use specific Transport 
protocol on default ports, can skip steps 7 to 10 and go directly to step II. 

8. SS responds with NAPTR response. 

9. UE initiates a DNS SRV query. 

10. SS responds with SRV response. 

1 1 . UE initiates a DNS AAAA query 

12. SS responds with DNS AAAA response. 

13. UE is made to initiate Registration procedure for IMS services. 

Expected sequence 



Step 


Direction 


lUlessage 


Comment 


UE SS 


1 


-^ 


Activate PDF Context Request 


UE sends this PDU not requesting for P-CSCF 
address{es) 


2 


<- 


Activate PDF Context Accept 


SS Sends this response including P-CSCF 
Address(es). UE shall either ignore the received 
address, or use the address. If UE uses address, go 
to step 13. 


3 


^ 


DHCP SOLICIT 




4 


-^ 


DHCP ADVERTISE 


Sent if DHCP Solicit message is received. 
Including P-CSCF Address(es). If P-CSCF IP 
addresses are included go to step 13, else go to 
step 7 


5 


^ 


DHCP Information-Request 


Requesting P-CSCF Address(es)* 


6 


^ 


DHCP Reply 


Including P-CSCF Address(es). If P-CSCF IP 
addresses are included go to step 13. 


7 


^ 


DNS NAPTR Query 


UE"s configured to use specific Transport protocol 
on default ports, can skip steps 7 to 10 and go 
directly to step 1 1 


8 


<- 


DNS NAPTR Response 




9 


■^ 


DNS SRV Query 




10 


-f- 


DNS SRV Response 




11 


^ 


DNS AAAA Query 




12 


-e 


DNS AAAA Response 




13 


^-» 


Registration 


UE is made to initiate Registration procedure to IIVIS 
services as defined in Annex A.2 Generic 
Registration Procedure. 



■ Note: UE may request all options in one Information Request or send multiple Information Requests. If UE opts 
for multiple Information Request transmissions, SS transmits accordingly multiple Reply messages 
including corresponding requested options. 
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Specific Message Contents: 

Step 2: Activate PDP Context Accept 



Options 


Value/Remarks 


Protocol Configuration options 




- Additional Parameters 




- container 1 Identifier 


0001 H{P-CSCF Address) 


-- Container 1 Length 


1 6 bytes 


-- Container 1 contents 


IPV6 address of SS 


- container 2 Identifier 


0003H (DNS Address) 


-- Container 2 Length 


1 6 bytes 


-- Container 2 contents 


IPV6 address of SS DNS Server 



Step 3: DHCP SOLICIT* 

Use the default message in annex B. 1 with the following exceptions 



Options 


Value/Remarks 


option-code 


OPTION_ORO (6) 


- option-len 


2 times number of requested options 


-requested-option-code-1 


OPTION SIP SERVER D(21)0R 
OPTION_SIP_SERVER_A (22) 


- requested-option-code-2 


OPTION_DNS_SERVERS (23) 


- requested-option-code-3 


OPTION DOMAIN LIST (24) 



*Note: Options can be optionally present and option codes can be in any order 

**Note: Numerical value, "(n)", provided in brackets in Column Value/Remarks is the 'octal' value for this option. 

Step 4: DHCP ADVERTISE 

Use the default message in annex B.l with the following exceptions 

Note: Options are included only if corresponding Requests are received. 

Case 1: OPTION_SIP_SERVER_D (21) ) or both (OPTION_SIP_SERVER_D (21) and 

OPTION_SIP_SERVER_A (22)) and OPTION_DOMAIN_LIST(24) or 
OPTION_DNS_SERVERS (23) received in step 3 



Options 



Value/Remarks 



option-code 
- option-len 
Domain-address 1 



OPTION_SIP_SERVER_D (21) 

Length of encoded domain address RFC 3319[51] 

SS P-CSCF server domain Address RFC 3319[51] 



option-code 
- option-len 
Domain-address 1 



OPTION_DNS_SERVERS (23) 

Length of encoded DNS server address RFC 3646[48] 

SS DNS server IPv6 address RFC 3646[48] 



option-code 
- option-len 
searchlist 



OPTION_DOMAIN_LIST (24) 

Length of Domain search list 

List of Domain Names encoded as per RFC 1035 [52] 
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*Note: Numerical value, "(n)", provided in brackets in Column Value/Remarks is the 'octal' value for this option. 



Case 2: OPTION_SIP_SERVER_A (22) received in step 3 



Options 



Value/Remarks 



option-code 
- option-len 
Domain-address 1 



OPTION_SIP_SERVER_A (22) 

128 

IPv6 address of SS P-CSCF Server 



option-code 
- option-len 
Domain-address 1 



OPTION_DNS_SERVERS (23) 

Length of encoded DNS server address RFC 3646[48] 

SS DNS server IPv6 address RFC 3646[48] 



option-code 
- option-len 
searchlist 



OPTION_DOMAIN_LIST (24) 

Length of Domain search list 

List of Domain Names encoded as per RFC 1035 [52] 



*Note: Numerical value, "(n)", provided in brackets in Column Value/Remarks is the 'octal' value for this option. 

Step 5: DHCP Information-Request 

Use the default message in annex B. 1 with the following exceptions 



Options 


Value/Remarks 


option-code 


OPTION_ORO (6) 


- option-len 


2 * number of requested options 


-requested-option-code-1 


OPTION SIP SERVER D(21)0R 
OPTION_SIP_SERVER_A (22) 


- requested-option-code-2 


OPTION_DNS_SERVERS(23)(Optional) 


- requested-option-code-3 


OPTION DOMAIN LIST (24) (Optional) 



Note: All options can be either received in one message or multiple messages. If more than one option codes 
present they can be in any order. 

*Note: Numerical value, "(n)", provided in brackets in Column Value/Remarks is the 'octal' value for this option. 

Step 6: DHCP Reply 

Use the default message in annex B. 1 with the following exceptions 

Note: Options are included only if corresponding Requests are received. 
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Case 1: OPTION_SIP_SERVER_D (21) ) or both (OPTION_SIP_SERVER_D (21) and 

OPTION_SIP_SERVER_A (22)) and OPTION_DOMAIN_LIST(24) or 
OPTION_DNS_SERVERS (23) received in step 5 



Options 



Value/Remarks 



option-code 
- option-len 
Domain-address 1 



OPTION_SIP_SERVER_D (21) 

Length of encoded domain address RFC 3319[51] 

SS P-CSCF server domain Address RFC 3319[51] 



option-code 
- option-len 
Domain-address 1 



OPTION_DNS_SERVERS (23) 

Length of encoded DNS server address RFC 3646[48] 

SS DNS server IPv6 address RFC 3646[48] 



option-code 
- option-len 
searchlist 



OPTION_DOMAIN_LIST (24) 

Length of Domain search list 

List of Domain Names encoded as per RFC 1035 [52] 



*Note: Numerical value, "(n)", provided in brackets in Column Value/Remarks is the 'octal' value for this option. 



Case 2: OPTION_SIP_SERVER_A (22) received in step 5 



Options 



Value/Remarks 



option-code 
- option-len 
Domain-address 1 



OPTION_SIP_SERVER_A (22) 

128 

IPv6 address of SS P-CSCF Server 



option-code 
- option-len 
Domain-address 1 



OPTION_DNS_SERVERS (23) 

Length of encoded DNS server address RFC 3646[48] 

SS DNS server IPv6 address RFC 3646[48] 



option-code 
- option-len 
searchlist 



OPTION_DOMAIN_LIST (24) 

Length of Domain search list 

List of Domain Names encoded as per RFC 1035 [52] 



*Note: Numerical value, "(n)", provided in brackets in Column Value/Remarks is the 'octal' value for this option. 
Step 7: DNS NAPTR Query 

Field Value/Remarks 



OPCODE^ 
QNAME= 
QCLASS= 
QTYPE= 



SQUERY 

P-CSCF domain name received 

IN 

NAPTR 
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Step 8: DNS NAPTR Response 

Field 

OPCODE= 
QNAME= 
QCLASS= 
QTYPE= 
NAPTR Records 



Value/Remarks 

SQUERY, RESPONSE, AA 

Same as received in NAPTR Query 

IN 

NAPTR 

NAPTR Records included for each Transport protocol 
(TLS, TCP, UDP) supported RFC 3263[50] 



Step 9: DNS SRV Query 



Field 



OPCODE= 
QNAME= 

QCLASS= 
QTYPE= 



Value/Remarks 



SQUERY 



Corresponding to the transport protocol selected by UE 
among those provided in DNS NAPTR Response 

IN 

SRV 



Step 10: DNS SRV Response 

Field 

QPCODE= 
QNAME= 
QCLASS= 
QTYPE= 
SRV Records 



Value/Remarks 

SQUERY, RESPONSE, AA 

Same as received in SRV Query 

IN 

NAPTR 

SRV Resource Record included providing the SS target 
server FQDN RFC 3263[50]. 



Step 1 1 : DNS AAAA Query 
Case 1 : steps 7 to 1 executed: 

Field 

QPCQDE= 
QNAIVIE= 

QCLASS= 
QTYPE= 



Value/Remarks 



SQUERY 



Selected P-CSCF name among provided in step 10 
based on priority and weight RFC 2728[56] 

IN 

AAAA 



Case 2: steps 7 to 1 not executed: 

Field 

QPCQDE= 
QNAME= 

QCLASS= 
QTYPE= 



Value/Remarks 



SQUERY 



Selected P-CSCF name among addresses provided in 
step 4 or 6. 

IN 

AAAA 
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Value/Remarks 

SQUERY, RESPONSE, AA 

Same as received in AAAA Query 

IN 

AAAA 

Includes resolved IP address(es). 



7.6.5 Test requirements 

1. In step 1, UE sends PDP Context Request message. 

2. After step 2, UE shall either ignore the received address, or use the address received. 

3. If UE ignores P-CSCF address in step 2, will send DHCP query in step 3 

4. After step 4 and 6, if P-CSCF IPv6 address is received UE will consider P-CSCF discovery procedure 
successful, else will initiate DNS query for domain address to IPv6 address translation. 

5) After step 12, UE will consider P-CSCF discovery procedure to be successful and should initiate Registration 
procedure to IMS services. 



8 Registration 

8.1 Initial registration 

8.1 .1 Definition and applicability 

Test to verify that the UE can correctly register to IMS services when equipped with UICC that contains either both 
ISIM and USIM applications or only USIM application but not ISIM. The process consists of sending initial registration 
to S-CSCF via the P-CSCF discovered, authenticating the user and finally subscribing the registration event package for 
the registered default public user identity. 

8.1.2 Conformance requirement 

If there is an ISIM and a USIM application on a UICC, then the ISIM application shall always be used for IMS 
authentication, as described in 3GPP TS 33.203. 

In case the UE is loaded with a UICC that contains the ISIM application, it will be preconfigured with all the necessary 
parameters to initiate the registration to the IM CN subsystem. These parameters include: 

the private user identity; 

one ore more public user identities; and 

the home network domain name used to address the SIP REGISTER request 

In case the UE is loaded with a UICC that does not contain the ISIM application, the UE shall: 

generate a private user identity; 

generate a temporary public user identity; and 

generate a home network domain name to address the SIP REGISTER request to. 
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All these three parameters are derived from the IMSI parameter in the USIM, according to the procedures described in 
3GPP TS 23.003. If the UICC does not contain the ISIM application, the UE shall derive new values every time the 
UICC is changed, and shall discard existing values if the UICC is removed. 

The temporary public user identity is only used in REGISTER requests, i.e. initial registration, re-registration, mobile- 
initiated deregistration. After a successful registration, the UE will get the associated public user identities, and the UE 
may use any of them in subsequent non-REGISTER requests. 

The UE shall not reveal to the user the temporary public user identity if the temporary public user identity is barred. The 
temporary public user identity is not barred if received by the UE in the P-Associated-URI header. 

The UE can register a public user identity at any time that a valid PDF context exists. However, the UE shall only 
initiate a new registration procedure when it has received a final response from the registrar for the ongoing registration, 
or the previous REGISTER request has timed out. 

The UE shall send only the initial REGISTER requests to the port advertised to the UE during the P-CSCF discovery 
procedure. If the UE does not receive any specific port information during the P-CSCF discovery procedure, the UE 
shall send the initial REGISTER request to the SIP default port values as specified in RFC 3261. 

A REGISTER request may be protected using a security association, see 3GPP TS 33.203 , established as a result of an 
earlier registration. 

The UE shall extract or derive from the UICC a public user identity, the private user identity, and the domain name to 
be used in the Request-URI in the registration, according to the procedures described in 3GPP TS 24.229 
subclause 5. 1 . 1 . 1 A. A public user identity may be input by the end user. 

On sending a REGISTER request, the UE shall populate the header fields as follows: 

a) the Authorization header, with: 

the username directive, set to the value of the private user identity; 

the realm directive, set to the domain name of the home network; 

the uri directive, set to the SIP URI of the domain name of the home network; 

the nonce directive, set to an empty value; and 

the response directive, set to an empty value. 

b) the From header set to the SIP URI that contains the public user identity to be registered; 

c) the To header set to the SIP URI that contains the public user identity to be registered; 

d) the Contact header set to include SIP URI(s) containing the IP address of the UE in the hostport parameter or 
FQDN. If the REGISTER request is protected by a security association, the UE shall also include the protected 
server port value in the hostport parameter; 

e) the Via header containing the IP address or FQDN of the UE in the sent-by field. If the REGISTER request is 
protected by a security association, the UE shall also include the protected server port value in the sent-by field. 

NOTE 1 : If the UE specifies its FQDN in the host parameter in the Contact header and in the sent-by field in the 

Via header, then it has to ensure that the given FQDN will resolve (e.g., by reverse DNS lookup) to the IP 
address that is bound to the security association. 

NOTE 2: The UE associates two ports, a protected client port and a protected server port, with each pair of security 
association. For details on the selection of the protected port value see 3GPP TS 33.203. 

f) the Expires header, or the expires parameter within the Contact header, set to the value of 600 000 seconds as the 
value desired for the duration of the registration; 

NOTE 3: The registrar (S-CSCF) might decrease the duration of the registration in accordance with network policy. 
Registration attempts with a registration period of less than a predefined minimum value defined in the 
registrar will be rejected with a 423 (Interval Too Brief) response. 

g) a Request-URI set to the SIP URI of the domain name of the home network; 
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h) the Security-Client header field set to specify the security mechanism the UE supports, the IPsec layer 

algorithms the UE supports and the parameters needed for the security association setup. The UE shall support 
the setup of two pairs of security associations as defined in 3GPP TS 33.203. The syntax of the parameters 
needed for the security association setup is specified in Annex H of 3GPP TS 33.203. The UE shall support the 
"ipsec-3gpp" security mechanism, as specified in RFC 3329. The UE shall support the HMAC-MD5-96 
(RFC 2403) and HMAC-SHA-1-96 (RFC 2404) IPsec layer algorithms, and shall announce support for them 
according to the procedures defined in RFC 3329; 

i) the Supported header containing the option tag "path"; and 

j) if a security association exists, a P- Access-Network-Info header that contains information concerning the access 
network technology and, if applicable, the cell ID. 

When a 401 (Unauthorized) response to a REGISTER is received the UE shall behave as described in 3GPP TS 24.229 
subclause 5.1.1.5.1. 

Authentication is achieved via the registration and re-registration procedures. When the network requires authentication 
or re-authentication of the UE, the UE will receive a 401 (Unauthorized) response to the REGISTER request. 

On receiving a 401 (Unauthorized) response to the REGISTER request, the UE shall: 

1) extract the RAND and AUTN parameters; 

2) check the validity of a received authentication challenge, as described in 3GPP TS 33.203 i.e. the locally 
calculated XMAC must match the MAC parameter derived from the AUTN part of the challenge; and the SQN 
parameter derived from the AUTN part of the challenge must be within the correct range; and 

3) check the existence of the Security-Server header as described in RFC 3329. If the header is not present or it 
does not contain the parameters required for the setup of the set of security associations (see annex H of 

3GPP TS 33.203), the UE shall abandon the authentication procedure and send a new REGISTER request with a 
new Call-ID. 

In the case that the 401 (Unauthorized) response to the REGISTER request is deemed to be valid the UE shall: 

1) calculate the RES parameter and derive the keys CK and IK from RAND as described in 3GPP TS 33.203; 

2) set up a temporary set of security associations based on the static list and parameters it received in the 401 
(Unauthorized) response and its capabilities sent in the Security-Client header in the REGISTER request. The 
UE sets up the temporary set of security associations using the most preferred mechanism and algorithm returned 
by the P-CSCF and supported by the UE and using IK as the shared key. The UE shall use the parameters 
received in the Security-Server header to setup the temporary set of security associations. The UE shall set a 
temporary SIP level lifetime for the temporary set of security associations to the value of reg-await-auth timer; 
and 

3) send another REGISTER request using the temporary set of security associations to protect the message. The 
header fields are populated as defined for the initial request, with the addition that the UE shall include an 
Authorization header containing the private user identity and the authentication challenge response calculated by 
the UE using RES and other parameters, as described in RFC 3310. The UE shall also insert the Security-Client 
header that is identical to the Security-Client header that was included in the previous REGISTER request (i.e. 
the REGISTER request that was challenged with the received 401 (Unauthorized) response). The UE shall also 
insert the Security- Verify header into the request, by mirroring in it the content of the Security-Server header 
received in the 401 (Unauthorized) response. The UE shall set the Call-ID of the integrity protected REGISTER 
request which carries the authentication challenge response to the same value as the Call-ID of the 401 
(Unauthorized) response which carried the challenge. 

On receiving the 200 (OK) response for the integrity protected REGISTER request, the UE shall: 

change the temporary set of security associations to a newly established set of security associations, i.e. set its 
SIP level lifetime to the longest of either the previously existing set of security associations SIP level lifetime, or 
the lifetime of the just completed registration plus 30 seconds; and 

use the newly established set of security associations for further messages sent towards the P-CSCF as 
appropriate. 
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NOTE: In this case, the UE will send requests towards the P-CSCF over the newly established set of security 
associations. Responses towards the P-CSCF that are sent via UDP will be sent over the newly 
established set of security associations. Responses towards the P-CSCF that are sent via TCP will be sent 
over the same set of security associations that the related request was received on. 

When the first request or response protected with the newly established set of security associations is received from the 
P-CSCF, the UE shall delete the old set of security associations and related keys it may have with the P-CSCF after all 
SIP transactions that use the old set of security associations are completed. 

On receiving the 200 (OK) response to the REGISTER request, the UE shall: 

a) store the expiration time of the registration for the public user identities found in the To header value; 

b) store the list of URIs contained in the P-Associated-URI header value. This list contains the URIs that are 
associated to the registered public user identity; 

c) store as the default public user identity the first URI on the list of URIs present in the P-Associated-URI header; 

d) treat the identity under registration as a barred public user identity, if it is not included in the P-Associated-URI 
header; 

e) store the list of Service-Route headers contained in the Service-Route header, in order to build a proper 
preloaded Route header value for new dialogs; and 

f) set the security association lifetime to the longest of either the previously existing security association lifetime (if 
available), or the lifetime of the just completed registration plus 30 seconds. 

Upon receipt of a 2xx response to the initial registration, the UE shall subscribe to the reg event package for the public 
user identity registered at the users registrar (S-CSCF) as described in RFC 3680. 

The UE shall use the default public user identify for subscription to the registration-state event package, if the public 
user identity that was used for initial registration is a barred public user identity. The UE may use either the default 
public user identity or the public user identity used for initial registration for the subscription to the registration-state 
event package, if the initial public user identity that was used for initial registration is not barred. 

On sending a SUBSCRIBE request, the UE shall populate the header fields as follows: 

a) a Request URI set to the resource to which the UE wants to be subscribed to, i.e. to a SIP URI that contains the 
public user identity used for subscription; 

b) a From header set to a SIP URI that contains the public user identity used for subscription; 

c) a To header set to a SIP URI that contains the public user identity used for subscription; 

d) an Event header set to the "reg" event package; 

e) an Expires header set to 600 000 seconds as the value desired for the duration of the subscription; and 

f) a P-Access-Network-Info header that contains information concerning the access network technology and, if 
applicable, the cell ID. 

The procedures of this subclause are general to all requests and responses, except those for the REGISTER method. 

When the UE sends any request, the UE shall: 

include the protected server port in the Via header entry relating to the UE; and 

include the protected server port in any Contact header that is otherwise included. 



The UE shall insert a P-Access-Network-Info header into any request for a dialog, any subsequent request (except ACK 
requests and CANCEL requests) or response (except CANCEL responses) within a dialog or any request for a 
standalone method. This header shall contain information concerning the access network technology and, if applicable, 
the cell ID. 
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The UE shall build a proper preloaded Route header value for all new dialogs and standalone transactions. The UE shall 
build a list of Route header values made out of, in this order, the P-CSCF URI (containing the IP address or the FQDN 
learnt through the P-CSCF discovery procedures, and the protected port learnt during the registration procedure), and 
the values received in the Service-Route header saved from the 200 (OK) response to the last registration or re- 
registration. 

Upon receipt of a 2xx response to the SUBSCRIBE request, the UE shall store the information for the established 
dialog and the expiration time as indicated in the Expires header of the received response. 

Upon receipt of a NOTIFY request on the dialog which was generated during subscription to the reg event package the 
UE shall perform the following actions: 

if a state attribute "active", i.e. registered is received for one or more public user identities, the UE shall store the 
indicated public user identities as registered; 

if a state attribute "terminated", i.e. deregistered is received for one or more public user identities, the UE shall 
store the indicated public user identities as deregistered. 

NOTE: There may be public user identities which are automatically registered within the registrar (S-CSCF) of 
the user upon registration of one public user identity. Usually these automatically or implicitly registered 
public user identities belong to the same service profile of the user and they might not be available within 
the UE. The implicitly registered public user identities may also belong to different service profiles. The 
here-described procedures provide a different mechanism (to the 200 (OK) response to the REGISTER 
request) to inform the UE about these automatically registered public user identities. 

Reference(s) 

3GPPTS 24.229[10], clauses 5.1.1.1A, 5.1.1.2, 5.1.1.3, 5.1.1.5.1, 5.1.2.1 and 5.1.2A.1 



8.1.3 Test purpose 



1) To verify that UE correctly derives a private user identity, a temporary public user identity and a home network 
domain name from the IMSI parameter in the USIM, according to the procedures described in 3GPP TS 23.003 
[32] clause 13 or alternatively uses the values retrieved from ISIM; and 

2) To verify that the UE sends a correctly composed initial REGISTER request to S-CSCF via the discovered P- 
CSCF, according to 3GPP TS 24.229 [10] clause 5.1.1.2; and 

3) To verify that after receiving a valid 401 (Unauthorized) response from S-CSCF for the initial REGISTER sent, 
the UE correctly authenticates itself by sending another REGISTER request with correctly composed 
Authorization header using AKAvl-MD5 algorithm (as described in RFC 3310 [17]); and 

4) To verify that the UE announces to support the "ipsec-3gpp" security mechanism together with HMAC-MD5-96 
(RFC 2403 [28]) and HMAC-SHA-1-96 (RFC 2404 [29]) IPsec layer algorithms according to the procedures 
defined in RFC 3329 [21]; and 

5) To verify that the UE supports both the HMAC-MD5-96 (RFC 2403 [28]) and HMAC-SHA-1-96 

(RFC 2404 [29]) IPsec layer algorithms for integrity protection and uses the one that is preferred by the P-CSCF 
according to the procedures defined in RFC 3329 [21]; and 

6) To verify that the UE sets up two pairs of security associations as defined in 3GPP TS 33.203 [14] clause 7 and 
uses those for sending the REGISTER request to authenticate itself and for sending any other subsequent 
request; and 

7) To verify that after receiving a valid 200 OK response from S-CSCF for the REGISTER sent for authentication, 
the UE stores the default public user identity and information about barred user identities; and 

8) To verify that after receiving a valid 200 OK response from S-CSCF for the REGISTER sent for authentication, 
the UE subscribes to the reg event package for the public user identity registered at the users registrar (S-CSCF) 
as described in RFC 3680 [22]; and 

9) To verify that the UE uses the default public user identify for subscription to the registration-state event package, 
when the public user identity that was used for initial registration is a barred public user identity; and 
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10) To verify that the UE uses the stored service route for routing the SUBSCRIBE sent; and 

1 l)To verify that after receiving a valid 200 OK response from S-CSCF to the SUBSCRIBE sent for registration 
event package, the UE maintains the generated dialog; and 

12) To verify that after receiving a valid NOTIFY for the registration event package, the UE will update and store 
the registration state of the indicated public user identities accordingly (as specified in RFC 3680 [22] clause 5); 
and 

13) To verify that the UE responds the received valid NOTIFY with 200 OK. 

8.1.4 Method of test 

Initial conditions 

UE contains either ISIM and USIM applications or only USIM application on UICC. UE is not registered to IMS 
services, but has an active PDP context and has discovered the SS as P-CSCF by executing the generic test procedure in 
Annex C.2 up to step 3. 

SS is configured with the IMSI within the USIM application, the home domain name, public and private user identities 
together with the shared secret key of IMS AKA algorithm, related to the IMS private user identity (IMPI) that is 
configured on the UICC card equipped into the UE. SS is listening to SIP default port 5060 for both UDP and TCP 
protocols. SS is able to perform AKAvl-MD5 authentication algorithm for that IMPI, according to 3GPP TS 33.203 
[14] clause 6.1 and RFC 3310 [17]. 

Related ICS/IXIT Statement(s) 



Test procedure 

1) IMS registration is initiated on the UE. SS waits the UE to send an initial REGISTER request. 

2) SS responds to the initial REGISTER request with a valid 401 Unauthorized response, headers populated 
according to the 401 response common message definition. 

3) SS waits for the UE to set up a temporary set of security associations and send another REGISTER request, over 
those security associations. 

4) SS responds to the second REGISTER request with valid 200 OK response, sent over the same temporary set of 
security associations that the UE used for sending the REGISTER request. SS shall populate the headers of the 
200 OK response according to the 200 response for REGISTER common message definition. 

5) SS waits for the UE to send a SUBSCRIBE request over the newly established security associations. 

6) SS responds to the SUBSCRIBE request with a valid 200 OK response, headers populated according to the 200 
response for SUBSCRIBE common message definition. 

7) SS sends UE a NOTIFY request for the subscribed registration event package. In the request the Request URI, 
headers and the request body shall be populated according to the NOTIFY common message definition. 

8) SS waits for the UE to respond the NOTIFY with 200 OK response. 

NOTE: This test case shall be run twice in order to test that the UE correctly supports both HMAC-MD5-96 and 
HMAC-SHA-1-96 algorithms. For each test round the name of the corresponding algorithm shall be 
configured into px_IpSecAlgorithm PIXIT. 
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Expected sequence 



Step 


Direction 


lUlessage 


Comment 


UE 1 SS 


1 


^ 


REGISTER 


UE sends initial registration for IIVIS services. 


2 


-^ 


401 Unauthorized 


The SS responds with a valid AKAv1-IVID5 
authentication challenge and security mechanisms 
supported by the network. 


3 


-^ 


REGISTER 


UE completes the security negotiation procedures, 
sets up a temporary set of SAs and uses those for 
sending another REGISTER with AKAvt-IVIDS 
credentials. 


4 


<- 


200 OK 


The SS responds with 200 OK. 


5 


■^ 


SUBSCRIBE 


UE subscribes to its registration event package. 


6 


^ 


200 OK 


The SS responds SUBSCRIBE with 200 OK 


7 


^ 


NOTIFY 


The SS sends initial NOTIFY for registration event 
package, containing full registration state 
information for the registered public user identity in 
the XML body 


8 


^ 


200 OK 


The UE responds the NOTIFY with 200 OK 



Specific Message Contents 

REGISTER (Step 1) 

Use the default message 'REGISTER' in annex A. 1.1 with condition Al "Initial unprotected REGISTER" 

401 Unauthorized for REGISTER (Step 2) 

Use the default message '401 Unauthorized for REGISTER' in annex A. 1.2 

REGISTER (Step 3) 

Use the default message 'REGISTER' in annex A. 1.1 with condition A2 "Subsequent REGISTER sent over security 
associations 

200 OK for REGISTER (Step 4) 

Use the default message '200 OK for REGISTER' in annex A. 1.3 

SUBSCRIBE (Step 5) 

Use the default message 'SUBSCRIBE for reg-event package' in annex A. 1.4 

200 OK for SUBSCRIBE (Step 6) 

Use the defauh message '200 OK for SUBSCRIBE' in annex A. 1.5 

NOTIFY (Step 7) 

Use the default message 'NOTIFY for reg-event package' in annex A. 1.6 

200 OK for NOTIFY (Step 8) 

Use the default message '200 OK for other requests than REGISTER or SUBSCRIBE' in annex A.3.1 



8.1.5 Test requirements 



Step 3: SS shall check that in accordance to the 3GPP TS 24.229 [10] clause 5.1.1.5 the UE sends another REGISTER 
request as follows: 



£75/ 



3GPP TS 34.229-1 version 5.0.0 Release 5 58 ETSI TS 134 229-1 V5.0.0 (2006-06) 

a) the UE sets up the temporary set of security associations between the ports announced in Security-Client header 
(UE) in the REGISTER request and Security-Server header (SS) in the 401 Unauthorized response; and 

b) the UE uses the most preferred mechanism and algorithm returned by the SS and supported by the UE for the 
temporary set of security associations; and 

c) the UE uses IK derived from RAND as the shared key for integrity protection for the temporary set of security 
associations; and 

d) the UE sends the second REGISTER over the temporary set of security associations; and 

Step 5: SS shall check that, in accordance to the 3GPP TS 24.229 [10] clause 5.1.1.3, the UE sends a SUBSCRIBE 
request for registration event package over the newly established set of security associations. 

NOTE: If the UE specifies its FQDN in the host parameter in the Contact header and in the sent-by field in the 
Via header (within any of the request sent by the UE), then SS has to ensure that the given FQDN will 
resolve (e.g., by reverse DNS lookup) to the IP address that is bound to the security association (or to the 
unprotected port in the initial REGISTER). 

8.2 User Initiated Re-Registration 

8.2.1 Definition 

Test to verify that the UE can re-register a previously registered public user identity at any time. This process is 
described in 3GPPTS 24.229 [10], clause 5.1.1.4 

8.2.2 Conformance requirement 

Unless either the user or the application within the UE has determined that a continued registration is not required the 

UE shall reregister the public user identity either 600 seconds before the expiration time if the initial registration was for 
greater than 1200 seconds, or when half of the time has expired if the initial registration was for 1200 seconds or less. 

The UE shall protect the REGISTER request using a security association, see 3GPP TS 33.203, established as a result 
of an earlier registration, if IK is available. 

The UE shall extract or derive from the UICC a public user identity, the private user identity, and the domain name to 
be used in the Request-URI in the registration, according to the procedures described in subclause 5. 1.1.1 A. 

On sending a REGISTER request that does not contain a challenge response, the UE shall populate the header fields as 
follows: 

a) an Authorization header, with with: 

the username directive set to the value of the private user identity; 

the realm directive, set to the domain name of the home network; 

the uri directive, set to the SIP URI of the domain name of the home network; 

the nonce directive, set to last received nonce value; and 

the response directive, set to the last calculated response; 

b) a From header set to the SIP URI that contains the public user identity to be registered; 

c) a To header set to the SIP URI that contains the public user identity to be registered; 

d) a Contact header set to include SIP URI(s) that contain(s) in the hostport parameter the IP address of the UE or 
FQDN and protected server port value bound to the security association; 

e) a Via header containing the IP address or FQDN of the UE in the sent-by field and the protected server port 
value bound to the security association; 
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NOTE 1 : If the UE specifies its FQDN in the host parameter in the Contact header and in the sent-by field in the 

Via header, then it has to ensure that the given FQDN will resolve (e.g., by reverse DNS lookup) to the IP 
address that is bound to the security association. 

NOTE 2: The UE associates two ports, a protected client port and a protected server port, with each pair of security 
associations. For details on the selection of the protected port value see 3GPP TS 33.203. 

f) an Expires header, or an expires parameter within the Contact header, set to 600 000 seconds as the value desired 
for the duration of the registration; 

NOTE 3: The registrar (S-CSCF) might decrease the duration of the registration in accordance with network policy. 
Registration attempts with a registration period of less than a predefined minimum value defined in the 
registrar will be rejected with a 423 (Interval Too Brief) response. 

g) a Request-URI set to the SIP URI of the domain name of the home network; 

h) a Security-Client header field, set to specify the security mechanism it supports, the IPsec layer algorithms it 
supports and the new parameter values needed for the setup of two new pairs of security associations. For further 
details see 3GPP TS 33.203 and RFC 3329; 

i) a Security- Verify header that contains the content of the Security-Server header received in the 401 
(Unauthorized) response of the last successful authentication; 

j) the Supported header containing the option tag "path"; and 

k) the P-Access-Network-Info header that contains information concerning the access network technology and, if 
applicable, the cell ID (see subclause 7.2A.4). 

On receiving the 200 (OK) response to the REGISTER request, the UE shall: 

a) store the new expiration time of the registration for this public user identity found in the To header value; 

b) store the list of URIs contained in the P-Associated-URI header value. This list contains the URIs that are 
associated to the registered public user identity; 

c) store the list of Service-Route headers contained in the Service-Route header, in order to build a proper 
preloaded Route header value for new dialogs; and 

d) set the security association lifetime to the longest of either the previously existing security association lifetime, 
or the lifetime of the just completed registration plus 30 seconds. 

When a 401 (Unauthorized) response to a REGISTER is received the UE shall behave as described in subclause 
5.1.1.5.1. On receiving a 423 (Interval Too Brief) response to the REGISTER request, the UE shall: 

- send another REGISTER request populating the Expires header or the expires parameter with an expiration timer 
of at least the value received in the Min-Expires header of the 423 (Interval Too Brief) response. 

NOTE: There may be public user identities which are automatically registered within the registrar (S-CSCF) of 
the user upon registration of one public user identity. Usually these automatically or implicitly registered 
public user identities belong to the same service profile of the user and they might not be available within 
the UE. The implicitly registered public user identities may also belong to different service profiles. The 
here-described procedures provide a different mechanism (to the 200 (OK) response to the REGISTER 
request) to inform the UE about these automatically registered public user identities. 

Reference(s) 

3GPP TS 24.229[10], clauses 5.1.1.4 

8.2.3 Test purpose 

1) To verify that the UE can re-register a previously registered public user identity at either 600 seconds before the 
expiration time if the initial registration was for greater than 1200 seconds, or when half of the time has expired 
if the initial registration was for 1200 seconds or less; and 
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2) Extract or derive from the UICC a public user identity, the private user identity, and the domain name to be used 
in the Request-URI in the registration; and 

3) To verify that the UE populates the header field in the REGISTER request with From, To, Via, Contact, 
Authorization, Expires, Security-Client, Security-verify, Supported, and P-Access-Network-Info headers; and 

4) Upon receiving 200 OK for REGISTER, the UE shall store the new expiration time of the registration for this 
public user identity, the list of URIs contained in the P-Associated-URI header value and use these values in the 
next re-register request. 

8.2.4 Method of test 

Initial conditions 

UE contains either ISIM and USIM applications or only USIM application on UICC. UE is not registered to 
IMS services, but has an active PDP context and has discovered the SS as P-CSCF by executing the 
generic test procedure in Annex C.2 up to step 3. 

SS is configured with the shared secret key of IMS AKA algorithm, related to the IMS private user identity (IMPI) 
configured on the UICC card equipped into the UE. SS is able to perform AKAvl-MD5 authentication algorithm for 
that IMPI, according to 3GPP TS 33.203 [14] clause 6.1 and RFC 3310 [17]. 

Related ICS/IXIT Statement(s) 



Test procedure 

1-8) The same procedure as in subclause 8.1.4 are used with the exception that the SS sets the expiration time to 120 
seconds in Step 4. 

9) Before half of the time has expired from the initial registration SS receives re-register message request with the 
From, To, Via, Contact, Authorization, Expires, Security-Client, Security-verify, Supported, and P-Access- 
Network-Info header fields. 

10) SS responds to the REGISTER request with valid 200 OK response with the list of URIs contained in the P- 
Associated-URI header value, the new expiration time (1200 seconds) of the registration for this public user 
identity,. 

1 1)SS waits for the REGISTER request and verifies it is received at least 600 seconds before the expected 
expiration time. 

12) SS responds to the REGISTER request with valid 200 OK response with the list of URIs contained in the P- 
Associated-URI header value, the new expiration time (1800 seconds) of the registration for this public user 
identity. 

13)SS waits for the REGISTER request and verifies it is received at least 600 seconds before the expected 
expiration time. 

14) SS responds to the REGISTER request with vaHd 200 OK response. SS shall populate the headers of the 200 OK 
response according to the 200 response for REGISTER common message definition. 
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Expected sequence 



Step 


Direction 


lUlessage 


Comment 


UE 1 SS 


1-8 




IVIessages in Initial Registration Test 
case (subclause 8.1.4) 


The same messages as in subclause 8.1 .4 are 
used with the exception that in Step 4, the SS 
responds with 200 OK indicating 120 seconds 
expiration time. 


9 


^ 


REGISTER 


The SS receives REGISTER from the UE 60 
seconds before the expiration time set in the initial 
registration request. 


106 


<- 


200 OK 


The SS responds with 200 OK indicating 1200 
seconds expiration time. 


11 


■^ 


REGISTER 


The SS receives REGISTER from the UE 600 
seconds before the expiration time set in step 6. 


128 


^ 


200 OK 


The SS responds with 200 OK indicating 1800 
seconds expiration time. 


13 


■^ 


REGISTER 


The SS receives REGISTER from the UE 600 
seconds before the expiration time set in step 8 


14 


^ 


200 OK 


The SS responds with 200 OK indicating the default 
expiration time. 



Specific Message Contents 

Messages in Step 1-8 

Messages in Step 1-8 are the same as those specified in subclause 8.1.4 with the following exception for the 200 OK for 
REGISTER in Step 4: 

Use the default message 'REGISTER' in annex A. 1.1 with condition Al "Subsequent REGISTER sent over security 
associations" and with the following exceptions: 



Header/param 


Value/remark 


Contact 
expires 


120 



REGISTER (Step 9) 

Use the default message 'REGISTER' in annex A. 1.1 with condition A2 "Subsequent REGISTER sent over security 
associations" and with the following exceptions: 



Header/param 


Value/remarl< 


Security-Client 

spi-c 
spi-s 
port-c 
port-s 


new SPI number of the inbound SA at the protected client port 

new SPI number of the inbound SA at the protected server port 

new protected client port needed for the setup of new pairs of security associations 

Same value as in the previous REGISTERS 



200 OK for REGISTER (Step 1 0) 

Use the default message '200 OK for REGISTER' in annex A. 1.3 with the following exceptions: 



Header/param 


Value/remark 


Contact 

expires 


1200 
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REGISTER (Step 11) 

Use the default message 'REGISTER' in annex A. 1.1 with condition A2 "Subsequent REGISTER sent over security 
associations" and with the following exceptions: 



Header/param 


Value/remark 


Security-Client 

spi-c 

spi-s 

port-c 

port-s 


new SPI number of the inbound SA at the protected client port, may or may not be 

the same as in step 1 

new SPI number of the Inbound SA at the protected server port, may or may not be 

the same as in step 1 

new protected client port needed for the setup of new pairs of security associations, 

may or may not be the same as in step 1 

Same value as In the previous REGISTERS 



200 OK for REGISTER (Step 12) 

Use the default message '200 OK for REGISTER' in annex A. 1.3 with the following exceptions: 



Header/param 


Value/remark 


Contact 

expires 


1800 



REGISTER (Step 13) 

Use the default message 'REGISTER' in annex A. 1.1 with condition A2 "Subsequent REGISTER sent over security 
associations" and with the following exceptions: 



Header/param 


Value/remark 


Security-Client 

spi-c 

spl-s 

port-c 

port-s 


new SPI number of the inbound SA at the protected client port, may or may not be 

the same as in step 1 and 3 

new SPI number of the inbound SA at the protected server port, may or may not be 

the same as in step 1 and 3 

new protected client port needed for the setup of new pairs of security associations, 

may or may not be the same as in step 1 or 3 

Same value as In the previous REGISTERS 



200 OK for REGISTER (Step 14) 

Use the default message '200 OK for REGISTER' in annex A. 1.3. 

8.2.5 Test requirements 

1 . The UE shall in step 9 send the REGISTER request within 60 seconds from the time instant that it receives 200 
OK in step 4 from the SSt 

2. The UE shall in step 1 1 send the REGISTER request within 600 seconds from the time instant that it receives 
200 OK from the SS in step 10.. 

3. The UE shall in step 13 send the REGISTER request within 1200 seconds from the time instant that it receives 
200 OK from the SS in step 12. 
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8.3 Mobile Initiated Deregistration 

8.3.1 Definition and applicability 

Test to verify that the UE can perform a correct de-registration procedure. This process is described in 3GPPTS 24.229 
[10], clause 5.1.1.6 

8.3.2 Conformance requirement 

The UE can deregister a previously registered public user identity at any time. 

The UE shall integrity protect the REGISTER request using a security association, see 3GPP TS 33.203, established as 
a result of an earlier registration, if one is available. 

The UE shall extract or derive from the UlCC a public user identity, the private user identity, and the domain name to 
be used in the Request-URl in the registration, according to the procedures described in subclause 5. 1.1.1 A. 

Prior to sending a REGISTER request for deregistration, the UE shall release all dialogs related to the public user 
identity that is going to be deregistered or to one of the implicitly registered public user identities. 

On sending a REGISTER request, the UE shall populate the header fields as follows: 

a) the Authorization header, with; 

the username directive, set to the value of the private user identity; 

the realm directive, set to the domain name of the home network; 

the uri directive, set to the SIP URI of the domain name of the home network; 

the nonce directive, set to last received nonce value; and 

the response directive, set to the last calculated response value; 

b) the From header set to the SIP URI that contains the public user identity to be deregistered; 

c) the To header set to the SIP URI that contains the public user identity to be deregistered; 

d) the Contact header set to either the value of "*" or SIP URI(s) that contain(s) in the hostport parameter the IP 
address of the UE or FQDN and the protected server port value bound to the security association; 

e) a Via header containing the IP address or FQDN of the UE in the sent-by field and the protected server port value 
bound to the security association; 

NOTE 1 : If the UE specifies its FQDN in the host parameter in the Contact header and in the sent-by field in the 
Via header, then it has to ensure that the given FQDN will resolve (e.g., by reverse DNS lookup) to the IP 
address that is bound to the security association. 

f) the Expires header, or the expires parameter of the Contact header, set to the value of zero, appropriate to the 
deregistration requirements of the user; 

g) a Request-URI set to the SIP URI of the domain name of the home network; and 

h) a P-Access-Network-Info header that contains information concerning the access network technology and, if 
applicable, the cell ID (see subclause 7.2A.4). 

On receiving the 200 (OK) response to the REGISTER request, the UE shall remove all registration details relating to 
this public user identity. 

If there are no more public user identities registered, the UE shall delete the security associations and related keys it 
may have towards the P-CSCF. 
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If all public user identities are deregistered and the security association is removed, then the UE shall consider 
subscription to the reg event package cancelled (i.e. as if the UE had sent a SUBSCRIBE request with an Expires 
header containing a value of zero). 

NOTE: When the UE has received the 200 (OK) response for the REGISTER request of the only public user 
identity currently registered with its associated set of implicitly registered public user identities (i.e. no 
other is registered), the UE removes the security association established between the P-CSCF and the UE. 
Therefore further SIP signalling (e.g. the NOTIFY request containing the deregistration event) will not 
reach the UE. 

Reference(s) 

3GPPTS 24.229 [10], clause 5.1.1.6 

8.3.3 Test purpose 

1) To verify that the UE sends a correctly composed initial REGISTER request with an Expires header or expires 
parameter set to to S-CSCF via the discovered P-CSCF, according to 3GPP TS 24.229 [10] clause 5.1.1.6. 

8.3.4 Method of test 

Initial conditions 

UE contains either ISIM and USIM applications or only USIM application on UICC. UE is registered to IMS services 
by performing the generic registration test procedure in Annex C up to the last step. 

SS is configured with the IMSI within the USIM application, the home domain name, public and private user identities 
together with the shared secret key of IMS AKA algorithm, related to the IMS private user identity (IMPI) that is 
configured on the UICC card equipped into the UE. SS is listening to SIP default port 5060 for both UDP and TCP 
protocols. SS is able to perform AKAvl-MD5 authentication algorithm for that IMPI, according to 3GPP TS 
33.203[14] clause 6.1 and RFC 3310 [17]. 

Related ICS/IXIT Statement(s) 

Method of triggering the UE to deregister from IMS services Yes/No 

Test procedure 

1) The UE is triggered by MMI to initiate a deregistration procedure 

2) IMS deregistration is initiated on the UE. SS waits the UE to send a REGISTER request, in accordance to 3GPP 
TS 24.229 [10], clause 5.1.1.6 

Expected sequence 



Step 


Direction 


lUlessage 


Comment 


UE SS 


1 


^ 


REGISTER 


UE sends deregistration for IMS services. (Register 
request with Expires header set to 0). 


2 


<- 


200 OK 


The SS responds REGISTER with 200 OK 
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Specific message contents 

REGISTER (step 1) 

SS shall check that in accordance to the 3GPP TS 24.229 [10] clause 5.1.1.6 the UE sends an initial REGISTER request 
where the Request-URI and the headers have been correctly populated according to the REGISTER common message 
definition in annex A. 1.1 condition A2 with the following exception: 



Header/param 


Value/remark 


Contact 

addr-spec 
expires 


SIP URI witli IP address or FQDN and protected server port of UE or * 
(if present, see Rule) 


Expires 

delta-seconds 


(if present, see Rule) 





Rule: if the addr-spec parameter of Contact header is *, expires parameter must not be present and Expires 
header is mandatory, if the addr-spec parameter of Contact header is not *, expires parameter is 
mandatory and Expires header must not be present. 

8.3.5 Test Requirements 

SS shall check in step 1 that the de-register request sent by the UE have the headers correctly populated as per the 
default message 'REGISTER' in annex A. 1.1 condition A2, except for the headers described in 8.3.4. 

8.4 Invalid behaviour- 423 Interval too brief 

8.4.1 Definition ancJ applicability 

Test to verify that the UE another REGISTER request using a correct expiration timer when a registration attempt was 
rejected with a 423 (Interval Too Brief) response. 

8.4.2 Conformance requirement 

On receiving a 423 (Interval Too Brief) too brief response to the REGISTER request, the UE shall: 

send another REGISTER request populating the Expires header or the expires parameter with an expiration timer 
of at least the value received in the Min-Expires header of the 423 (Interval Too Brief) response. 

Reference(s) 

3G TS 24.229 [10], clause 5.1.1.2 

8.4.3 Test purpose 

To verify that after receiving a valid 423 (Interval Too Brief) response to the REGISTER request, the UE sends another 
REGISTER request populating the Expires header or the expires parameter in the Contact header with an expiration 
timer of at least the value received in the Min-Expires header of the 423 (Interval Too Brief) response. 

8.4.4 Method of test 

Initial conditions 

UE contains either ISIM and USIM applications or only USIM application on UICC. UE is not registered to IMS 
services, but has an active PDP context and has discovered the SS as P-CSCF by executing the generic test procedure in 
Annex C.2 up to step 3. 
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SS is configured with the IMSI within the USIM application, the home domain name, public and private user identities 
together with the shared secret key of IMS AKA algorithm, related to the IMS private user identity (IMPI) that is 
configured on the UICC card equipped into the UE. SS is listening to SIP default port 5060 for both UDP and TCP 
protocols. 

Related ICS/IXIT Statement(s) 
<To be added> 

Test procedure 

1 IMS registration is initiated on the UE. SS waits for the UE to send an initial REGISTER request. 

2 SS responds to the initial REGISTER request with a 423 (Interval Too Brief) response because the expiration 
time of the resource refreshed by the request is too short. 

3 SS waits for the UE to send another REGISTER request populating the Expires header or the expires parameter 
in the Contact header with an expiration timer of at least the value received in the Min-Expires header of the 423 
(Interval Too Brief) response. 

Expected sequence 



Step 


Direction 


Message 


Comment 


UE 1 SS 


1 


-^ 


REGISTER 


UE sends initial registration for IIVIS services. 


2 


<- 


423 Interval Too Brief 


The SS responds with a 423 (Interval Too Brief) too 
brief response to the REGISTER request with T 
value in Min-Expires header 


3 


■^ 


REGISTER 


UE sends a new REGISTER request with expires 
parameter value set to Tmod (equal or greater to T 
value in Min-Expires header of 423 Interval Too 
Brief ) 



Specific Message Contents 

REGISTER (Step 1) 

Use the default message 'REGISTER' in annex A. 1.1 with condition Al 'Initial unprotected REGISTER'. 

423 Interval Too Brief for REGISTER (Step 2) 

Use the default message '423 Interval Too Brief for REGISTER' in annex A. 1 .7 with the following exception: 

Header/param Value/remark 



IVIin-Expires 

delta-seconds 



800000 (referred to as T in the test procedure and test requirement) 



REGISTER (Step 3) 

Use the default message 'REGISTER' in annex A. 1.1 with condition A2 "Subsequent REGISTER sent over security 
associations" with the following exception: 



Header/param 



Value/remark 



Contact 

expires 



800000 (referred to as Tmod in the expected sequence) 
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8.4.5 Test requirements 

Step 3: The UE shall send another REGISTER request populating the Expires header or the expires parameter in the 
Contact header with an expiration timer of at least the value received in the Min-Expires header of the 423 (Interval Too 
Brief) response. 

9 Authentication 

9.1 Invalid Behaviour - MAC Parameter Invalid 
9.1.1 Definition 

To test that the UE when receiving an invalid 401 (Unauthorized) response to its initial REGISTER request behaves 
correctly. This procedure is described in 24.229 [10] clause 5.1.1.5. 



9.1.2 Conformance requirement 



Whenever the 200 (OK) response is not received before the temporary SIP level lifetime of the temporary set of security 
associations expires or a 403 (Forbidden) response is received, the UE shall consider the registration to have failed. The 
UE shall delete the temporary set of security associations it was trying to establish, and use the old set of security 
associations. The UE should send an unprotected REGISTER message according to the procedure specified in 
subclause 5.1.1.2 if the UE considers the old set of security associations to be no longer active at the P-CSCF. 



When the network requires authentication of the UE, the UE will receive a 401 (Unauthorized) response to the 
REGISTER request. 

On receiving a 401 (Unauthorized) response to the REGISTER request, the UE shall: 

1) extract the RAND and AUTN parameters; 

2) check the validity of a received authentication challenge, as described in 3GPP TS 33.203 i.e. the locally 
calculated XMAC must match the MAC parameter derived from the AUTN part of the challenge; and the SQN 
parameter derived from the AUTN part of the challenge must be within the correct range; and 



If, in a 401 (Unauthorized) response, either the MAC or SQN is incorrect the UE shall respond with a further 
REGISTER indicating to the S-CSCF that the challenge has been deemed invalid as follows: 

in the case where the UE deems the MAC parameter to be invalid the subsequent REGISTER request shall 
contain noAUTS directive and an empty response directive, i.e. no authentication challenge response; 

in the case where the UE deems the SQN to be out of range, the subsequent REGISTER request shall contain the 
AUTS directive (see 3GPP TS 33.102 ). 

NOTE: In the case of the SQN being out of range, a response directive can be included by the UE, based on the 
procedures described in RFC 3310. Whenever the UE detects any of the above cases, the UE shall: 

send the REGISTER request using an existing set of security associations, if available (see 3GPP TS 33.203); 

populate a new Security-Client header within the REGISTER request, set to specify the security mechanism it 
supports, the IPsec layer algorithms it supports and the parameters needed for the new security association setup; 
and 

not create a temporary set of security associations. 

A UE shall only respond to two consecutive invalid challenges. The UE may attempt to register with the network again 
after an implementation specific time. 
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Reference(s) 

3GPPTS 24.229[10], clauses 5.1.1.5 

9.1.3 Test purpose 

1) To verify that after receiving a 401 (Unauthorized) response from S-CSCF for the initial REGISTER sent, the 
UE checks the validity of the received authentication challenge, as described in 3GPP TS 33.203 [14] i.e. the 
locally calculated XMAC must match the MAC parameter derived from the AUTN part of the challenge 

2) If, the value of MAC derived from the AUTN part of the 401 (Unauthorized) received by the UE does not match 
the value of locally calculated XMAC: 

the UE responds with a further REGISTER indicating to the S-CSCF that the challenge has been deemed 
invalid and: 

this subsequent REGISTER request contains no AUTS directive and an empty response directive, i.e. no 
authentication challenge response- populates a new Security-Client header within the REGISTER request, 
set to specify the security mechanism it supports, the IPsec layer algorithms it supports and the parameters 
needed for the new security association setup; and 

does not create a temporary set of security associations. 

9.1.4 Method of test 

Initial conditions 

UE contains either ISIM and USIM applications or only USIM application on UICC. UE is not registered to IMS 
services, but has an active PDP context and has discovered the SS as P-CSCF by executing the generic test procedure in 
Annex C.2 up to step 3. 

SS is configured with the shared secret key of IMS AKA algorithm, related to the IMS private user identity (IMPI) 
configured on the UICC card equipped into the UE. SS is able to perform AKAvl-MD5 authentication algorithm for 
that IMPI, according to 3GPP TS 33.203 [14] clause 6.1 and RFC 3310 [17]. SS is listening to SIP default port 5060 for 
both UDP and TCP protocols. 

Related ICS/IXIT Statement(s) 
<To be added> 

Test procedure 

1) IMS registration is initiated on the UE. SS waits for the UE to send an initial REGISTER request, in accordance 
to 3GPP TS 24.229 [10], clause 5.1.1.2 

2) SS responds to the initial REGISTER request with an invalid 401 Unauthorized response, headers populated as 
follows: 

a) To, From, Via, CSeq, Call-ID and Content-Length headers according to RFC 3261 [15] clauses 8.2.6.2 and 
20.14; and 

b) WWW -Authentication header with AKAvl-MD5 authentication challenge according to in 3GPP TS 24.229 
[10], clause 5.4.1.2.1 and RFC 3310 [17] clause 3; except that the MAC value in AUTN should be incorrect 
and the CK and IK values are not included 

c) Security-Server header according to 3GPP TS 24.229 [10], clause 5.2.2 and RFC 3329 [21] clause 2. 

3) SS waits for the UE to send a second Registration message indicating that the received 401 (Unauthorized) 
message was invalid 

4) SS sends an invalid 401 (UNAUTHORIZED) message, same as in step b) 
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5) SS waits for the UE to send a second Registration message indicating that the received 401 (Unauthorized) 
message was invahd 

Note: From this point onward the SS shall ignore any Registration message sent by the UE. 

6) SS sends a 403 (Forbidden) message to the UE (to get the UE in a stable state at the end of the test case). 

Expected sequence 



Step 


Direction 


lUlessage 


Comment 


UE 1 SS 


1 


^ 


REGISTER 


UE sends initial registration for IIVIS services. 


2 


-^ 


401 Unauthorized 


The SS responds with an invalid AKAvl-IVIDS 
authentication challenge with an invalid MAC value. 


3 


^ 


REGISTER 


REGISTER request: 

- - contains no AUTS directive and an empty 
response directive, i.e. no authentication challenge 
response 

- UE populates a new Security-Client header set to 
specify the security mechanism it supports, the 
IPsec layer algorithms it supports and the 
parameters needed for the new security association 
setup 


4 


-^ 


401 Unauthorized 


The SS responds with an invalid AKAvl-IVIDS 
authentication challenge with an invalid IVIAC value. 


5 


^ 


REGISTER 


REGISTER request: 

- contains no AUTS directive and an empty 
response directive, i.e. no authentication challenge 
response 

- UE populates a new Security-Client header set to 
specify the security mechanism it supports, the 
IPsec layer algorithms it supports and the 
parameters needed for the new security association 
setup 








Note: From this point onward the SS shall ignore 
any Registration message sent by the UE. 


6 


^ 


403 Forbidden 


The SS sends this message to get the UE in a 
stable state. 



Specific message contents 

401 UNAUTHORIZED (Steps 2 and 4) 

Use the default message '401 Unauthorized for REGISTER' in annex A. 1.2 with the following modification: 



Header/param 


Value/remark 


www-Authenticate 

nonce 


Base 64 encoding of RAND and AUTN, incorrect MAC 
value is used to generate 
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REGISTER (Step 1) 

Use the default message 'REGISTER' in annex A. 1.1 with condition Al 

REGISTER (Steps 3 and 5) 

Use the default message 'REGISTER' in annex A. 1.1 with condition Al with the following exceptions: 



Header/param 


Value/remark 


CSeq 

value 


The value sent in the previous REGISTER message + 1 (incremented) 


Call-ID 

Call-ID 


The same value as in REGISTER in Step 1 


Security-Verify 


Header must not appear in the request 


Authorization 

response 

auth-param 

nonce-count 


It should be present but empty 

If present it should not contain the auts='<base 64 encoded value>' directive 

value or presence of the parameter not to be checked 



403 FORBIDDEN (Step 6) 



Header/param 


Value/remark 


Rel 


Reference 


Status-Line 

SIP-Version 
Status-Code 
Reason-Phrase 


SIP/2.0 

403 

Forbidden 




RFC 3261 [15] 


Via 

via-parm 


same value as received in the previous REGISTER message 




RFC 3261 [15] 


To 

addr-spec 
tag 


same value as received in the previous REGISTER message 
pxToTagRegister 




RFC 3261 [15] 


From 

addr-spec 


same value as received in the previous REGISTER message 




RFC 3261 [15] 


Call-ID 

value 


same value as received in the previous REGISTER message 




RFC 3261 [15] 


CSeq 

value 


same value as received in the previous REGISTER message 




RFC 3261 [15] 


Content-length 

value 







RFC 3261 [15] 




RFC 3261 [15] 



Editor"s note: This table has got a special format with 2 extra columns as this message is supposed to be moved to 
the default messages from the next meeting. 



9.1 .5 Test requirements 

SS shall check in step 3 and 5 that in accordance to the 3GPP TS 24.229 [10] clause 5.1.1.5 

the UE responds with a further REGISTER indicating to the S-CSCF that the challenge has been deemed invalid 
and: 

sends the REGISTER request using no security associations; and 

the REGISTER request contains no AUTS directive and an empty response directive, i.e. no authentication 
challenge; and 
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populates a new Security-Client header within the REGISTER request, set to specify the security mechanism it 
supports, the IPsec layer algorithms it supports and the parameters needed for the new security association setup; 
and 

does not create a temporary set of security associations. 

9.2 Invalid Behaviour - SQN out of range 

9.2.1 Definition 

To test that the UE when receiving an invalid 401 (Unauthorized) response to its initial REGISTER request behaves 
correctly. This procedure is described in 24.229 [10] clause 5.1.1.5. 

To test after a failed authentication attempt that the UE when receiving a valid 401 (Unauthorized) response to its 
initial REGISTER request behaves correctly. This procedure is described in 24.229 [10] clause 5.1.1.5. 

9.2.2 Conformance requirement 

When the network requires authentication of the UE, the UE will receive a 401 (Unauthorized) response to the 
REGISTER request. 

On sending a REGISTER request, the UE shall populate the header fields as follows: 

a) the Authorization header, with the usemame field, set to the value of the private user identity; 

b) the From header set to the SIP URI that contains the public user identity to be registered; 

c) the To header set to the SIP URI that contains the public user identity to be registered; 

d) the Contact header set to include SIP URI(s) containing the IP address of the UE in the hostport parameter or 
FQDN. If the REGISTER request is protected by a security association, the UE shall also include the protected 
server port value in the hostport parameter; 

e) the Via header containing the IP address or FQDN of the UE in the sent-by field. If the REGISTER request is 
protected by a security association, the UE shall also include the protected server port value in the sent-by field. 

NOTE 1 : If the UE specifies its FQDN in the host parameter in the Contact header and in the sent-by field in the 

Via header, then it has to ensure that the given FQDN will resolve (e.g., by reverse DNS lookup) to the IP 
address that is bound to the security association. 

NOTE 2: The UE associates two ports, a protected client port and a protected server port, with each pair of security 
association. For details on the selection of the protected port value see 3GPP TS 33.203. 

f) the Expires header, or the expires parameter within the Contact header, set to the value of 600 000 seconds as the 
value desired for the duration of the registration; 

NOTE 3: The registrar (S-CSCF) might decrease the duration of the registration in accordance with network policy. 
Registration attempts with a registration period of less than a predefined minimum value defined in the 
registrar will be rejected with a 423 (Interval Too Brief) response. 

g) a Request-URI set to the SIP URI of the domain name of the home network; 

h) the Security-Client header field set to specify the security mechanism the UE supports, the IPsec layer 

algorithms the UE supports and the parameters needed for the security association setup. The UE shall support 
the setup of two pairs of security associations as defined in 3GPP TS 33.203 . The syntax of the parameters 
needed for the security association setup is specified in Annex H of 3GPP TS 33.203. The UE shall support the 
"ipsec-3gpp" security mechanism, as specified in RFC 3329. The UE shall support the HMAC-MD5-96 
(RFC 2403 ) and HMAC-SHA-1-96 (RFC 2404 ) IPsec layer algorithms, and shall announce support for them 
according to the procedures defined in RFC 3329; 

i) the Supported header containing the option tag "path"; and 
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j) if a security association exists, a P- Access-Network-Info header that contains information concerning the access 
network technology and, if applicable, the cell ID (see subclause 7.2A.4). 

On receiving a 401 (Unauthorized) response to the REGISTER request, the UE shall: 

1) extract the RAND and AUTN parameters; 

2) check the validity of a received authentication challenge, as described in 3GPP TS 33.203 i.e. the locally 
calculated XMAC must match the MAC parameter derived from the AUTN part of the challenge; and the SQN 
parameter derived from the AUTN part of the challenge must be within the correct range; and 

3) check the existence of the Security-Server header as described in RFC 3329. If the header is not present or it 
does not contain the parameters required for the setup of the set of security associations (see annex H of 

3GPP TS 33.203), the UE shall abandon the authentication procedure and send a new REGISTER request with a 
new Call-ID. 

In the case that the 401 (Unauthorized) response to the REGISTER request is deemed to be valid the UE shall: 

1) calculate the RES parameter and derive the keys CK and IK from RAND as described in 3GPP TS 33.203; 

2) set up a temporary set of security associations based on the static list and parameters it received in the 401 
(Unauthorized) response and its capabilities sent in the Security-Client header in the REGISTER request. The 
UE sets up the temporary set of security associations using the most preferred mechanism and algorithm returned 
by the P-CSCF and supported by the UE and using IK as the shared key. The UE shall use the parameters 
received in the Security-Server header to setup the temporary set of security associations. The UE shall set a 
temporary SIP level lifetime for the temporary set of security associations to the value of reg-await-auth timer; 
and 

3) send another REGISTER request using the temporary set of security associations to protect the message. The 
header fields are populated as defined for the initial request, with the addition that the UE shall include an 
Authorization header containing the private user identity and the authentication challenge response calculated by 
the UE using RES and other parameters, as described in RFC 3310. The UE shall also insert the Security-Client 
header that is identical to the Security-Client header that was included in the previous REGISTER request (i.e. 
the REGISTER request that was challenged with the received 401 (Unauthorized) response). The UE shall also 
insert the Security- Verify header into the request, by mirroring in it the content of the Security-Server header 
received in the 401 (Unauthorized) response. The UE shall set the Call-ID of the integrity protected REGISTER 
request which carries the authentication challenge response to the same value as the Call-ID of the 401 
(Unauthorized) response which carried the challenge. 



If, in a 401 (Unauthorized) response, either the MAC or SQN is incorrect the UE shall respond with a further 
REGISTER indicating to the S-CSCF that the challenge has been deemed invalid as follows: 

in the case where the UE deems the MAC parameter to be invalid the subsequent REGISTER request shall 
contain no AUTS directive and an empty response directive, i.e. no authentication challenge response; 

in the case where the UE deems the SQN to be out of range, the subsequent REGISTER request shall contain the 
AUTS directive(see 3GPP TS 33.102). 

NOTE: In the case of the SQN being out of range, a response directive can be included by the UE, based on the 
procedures described in RFC 3310. 

Whenever the UE detects any of the above cases, the UE shall: 

send the REGISTER request using an existing set of security associations, if available (see 3GPP TS 33.203); 

populate a new Security-Client header within the REGISTER request, set to specify the security mechanism it 
supports, the IPsec layer algorithms it supports and the parameters needed for the new security association setup; 
and 

not create a temporary set of security associations. 
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A UE shall only respond to two consecutive invalid challenges. The UE may attempt to register with the network again 
after an implementation specific time. 

Reference(s) 

3GPPTS 24.229 [10], clauses 5 . 1 . 1 .2 and 5 . 1 . 1 .5 

9.2.3 Test purpose 

1) To verify that after receiving a 401 (Unauthorized) response for the initial REGISTER sent, the UE checks that 
the SQN parameter derived from the AUTN part of the authentication challenge is within the correct range 

2) If, the value of SQN derived from the AUTN part of the 401 (Unauthorized) received by the UE is out of range 
the UE reacts correctly: 

3) To verify after a failed authentication attempt if the UE on receives a valid 401 (Unauthorized) message from 
the network in response to the Register request sent, the UE is able to perform the authentication and registration 
successfully: 

9.2.4 Method of test 

Initial conditions 

UE contains either ISIM and USIM applications or only USIM application on UICC. UE is not registered to IMS 
services, but has an active PDP context and has discovered the SS as P-CSCF by executing the generic test procedure in 
Annex C.2 up to step 3. 

SS is configured with the shared secret key of IMS AKA algorithm, related to the IMS private user identity (IMPI) 
configured on the UICC card equipped into the UE. SS is able to perform AKAvl-MD5 authentication algorithm for 
that IMPI, according to 3GPP TS 33.203 [14] clause 6.1 and RFC 3310 [17]. SS is listening to SIP default port 5060 for 
both UDP and TCP protocols. 

Related ICS/IXIT Statement(s) 
<To be added> 

Test procedure 

1) IMS registration is initiated on the UE. SS waits for the UE to send an initial REGISTER request, in accordance 
to 3GPP TS 24.229 [10], clause 5.1.1.2 

2) SS responds to the initial REGISTER request with an invalid 401 Unauthorized response, headers populated as 
follows: 

a) To, From, Via, CSeq, Call-ID and Content-Length headers according to RFC 3261 [15] clauses 8.2.6.2 and 
20.14; and 

b) WWW -Authentication header with AKAvl-MD5 authentication challenge according to in 3GPP TS 24.229 
[10], clause 5.4.1.2.1 and RFC 3310 [17] clause 3; except that the SQN value in AUTN should be out of 
range and the CK and IK values are not included 

c) Security-Server header according to 3GPP TS 24.229 [10], clause 5.2.2 and RFC 3329 [21] clause 2. 

3) SS waits for the UE to send a second Registration message indicating that the received 401 (Unauthorized) 
message was invalid 

4) SS sends a valid 401 (Unauthorized) message to the UE 

5) SS waits for the UE to send a Registration request using the temporary set of security associations to protect the 
message. The Registration request shall contain the valid answer to the authentication challenge in 401 
(Unauthorized) sent in the previous step 
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6.) SS responds to the second REGISTER request with valid 200 OK response, sent over the same temporary set of 
security associations that the UE used for sending the REGISTER request. SS shall populate the headers of the 
200 OK response according to the 200 response for REGISTER common message definition. 

Expected sequence 



Step 


Direction 


Message 


Comment 


UE 1 SS 


1 


-> 


REGISTER 


UE sends initial registration for IMS services. 


2 


^ 


401 Unauthorized 


The SS responds with an invalid AKAvl-IVIDS 
authentication challenge with SON out of range. 


3 


^ 


REGISTER 


REGISTER request: 

- contains AUTS directive 

- UE populates a new Security-Client header set to 
specify the security mechanism it supports, the 
IPsec layer algorithms it supports and the 
parameters needed for the new security association 
setup 


4 


^ 


401 Unauthorized 


This is a valid 401 (Unauthorized) message 


5 


^ 


REGISTER 


IVIessage is sent using the temporary set of security 
associations to protect the message 
Contains the valid answer to the authentication 
challenge sent in the 401 (Unauthorized) message 


6 


<- 


200 OK 


The SS responds with 200 OK. 



Specific message contents 

REGISTER (Step 1) 

Use the default message 'REGISTER' in annex A. 1.1 with condition Al. 

401 UNAUTHORIZED (Step 2) 

Use the default message '401 Unauthorized for REGISTER' in annex A. 1.2 with the following modification: 



Header/param 


Value/remark 


www-Authenticate 




nonce 


Base 64 encoding of RAND and AUTN, Generated with SON out 




of range 



REGISTER (Step 3) 

Use the default message 'REGISTER' in annex A. 1.1 with condition Al with the following exceptions: 



Header/param 


Value/remark 


CSeq 

value 


The value sent in the previous REGISTER message + 1 (incremented) 


Call-ID 

Call-ID 


The same value as in REGISTER in Step 1 


Authorization 

nonce 

opaque 

response 

auth-param 

nonce-count 


Same value as the opaque value in the previous 401 UNAUTHORIZED message 

Same value as the opaque value in the previous 401 UNAUTHORIZED message 

parameter must exist, but value not to be checked 

auts= LDQUOT auts-value RDQUOT, auts-value not to be checked 

value or presence of the parameter not to be checked 
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REGISTER (Step 5) 

Use the default message 'REGISTER' in annex A. 1 . 1 with option A2 with the following exceptions: 



Header/param 


Value/remark 


CSeq 

value 


The value sent in the previous REGISTER message + 1 (incremented) 


Call-ID 

Call-ID 


The same value as in REGISTER in Step 1 



Note: This message should be sent using the temporary set of security associations to protect the message. 

9.2.5 Test requirements 

SS shall check in step 3 that in accordance to the 3GPP TS 24.229 [10] clause 5.1.1.5 

the UE responds with a further REGISTER indicating to the S-CSCF that the challenge has been deemed invalid 
and: 

sends the REGISTER request using no security associations; and 

the REGISTER request contains AUTS directive; and 

populates a new Security-Client header within the REGISTER request, set to specify the security mechanism it 
supports, the IPsec layer algorithms it supports and the parameters needed for the new security association setup; 
and 

does not create a temporary set of security associations. 

SS shall check that in step 5 the UE: 

Sends the Registration request using the temporary set of security associations to protect the message 

The header fields are populated as defined for the initial request, with the addition that the UE shall include an 
Authorization header containing the private user identity and the authentication challenge response calculated by 
the UE using RES and other parameters, as described in RFC 3310 [17] 

inserts the Security-Client header into the request that is identical to the Security-Client header that was included 
in the previous REGISTER request(the message sent in step 3 ) 

inserts the Security- Verify header into the request, by mirroring in it the content of the Security-Server header 
received in the 401 (Unauthorized) response 

sets the Call-ID of the integrity protected REGISTER request which carries the authentication challenge 
response to the same value as the Call-ID of the 401 (Unauthorized) response which carried the challenge(the 
message sent in step 4 ) 



10 Subscription 

1 0.1 Invalid Behaviour - 503 Service Unavailable 



10.1.1 Definition and applicability 



Test to verify that when the UE receives a 503 (Service Unavailable) response to a SUBSCRIBE request containing a 
Retry- After header, then the UE shall not automatically reattempt the request until after the period indicated by the 
Retry-After header contents. This can happen when the server is temporarily unable to process the request due to a 
temporary overloading or maintenance of the server. 
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10.1.2 Conformance requirement 



If the UA receives a 503 (Service Unavailable) response to an initial SUBSCRIBE request containing a Retry- After 
header, then the UE shall not automatically reattempt the request until after the period indicated by the Retry- After 
header contents. 

Reference(s) 

3G TS 24.229 [10], clause 5.1.2.2 

10.1.3 Test purpose 

To verify that after receiving a 503 (Service Unavailable) response to a SUBSCRIBE request, containing a Retry-After 
header, the UE shall not automatically reattempt the request until after the period indicated by the Retry- After header 
contents. This can happen when the server is temporarily unable to process the request due to a temporary overloading 
or maintenance of the server. 

10.1.4 Method of test 

Initial conditions 

UE contains either ISIM or USIM application or only one USIM application on UICC. UE has an active PDF context, 
discovered the SS as P-CSCF and registered to IMS services by executing the generic test procedure in Annex C.2 up to 
step 7. 

SS is configured with the shared secret key of IMS AKA algorithm, related to the IMS private user identity (IMPI) 
configured on the UICC card equipped into the UE. SS has performed AKAvl-MD5 authentication with the UE and 
accepted the registration. 

Related ICS/IXIT Statement(s) 
<To be added> 

Test procedure 

1) The UE sends a SUBSCRIBE request over the established security associations. 

2) The SS responds to the SUBSCRIBE request with a 503 (Service Unavailable) response with the Retry-After 
header with period set to T, indicating how long the service is expected to be unavailable to the requesting client. 

3) The SS waits for the period of time T defined in the Retry-After header, to check that the UE does not try to 
SUBSCRIBE for the registration event during this period.. 

4) The UE sends a new SUBSCRIBE request and the SS responds with a valid 200 OK response. 
Expected sequence 



Step 


Direction 


Message 


Comment 


UE 1 SS 


1 


^ 


SUBSCRIBE 


UE subscribes to its registration event package. 


2 


-e 


503 Service Unavailable 


The SS responds with 503 response containing a 
Retry-After header with period set to T 


3 






SS waits for Time T to check that the UE does not 
re-attempt the request . 


4 


^ 


SUBSCRIBE 


UE reattempts to subscribe to its registration event 
package. 


5 


<- 


200 OK 


SS responds to SUBSCRIBE with 200 OK 
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Specific Message Contents 

SUBSCRIBE (Step 1) 

Use the default message 'SUBSCRIBE for reg-event package' in annex A. 1.4 . 

503 Service Unavailable response (Step 2) 
Header/param Value/remark 



Retry-after 




period 


60 (referred to as T in the test procedure and test requirement) 


duration 


Not present 


comment 


Not present 



SUBSCRIBE (Step 4) 

Use the default message 'SUBSCRIBE for reg-event package' in annex A. 1.4 with the following exception: 

Header/param Value/remark 

Call-ID 

callid value different from the previous SUBSCRIBE request 

200 OK for SUBSCRIBE (Step 5) 

Use the default message '200 OK for SUBSCRIBE' in annex A.1.5 . 

1 0.1 .5 Test requirements 

Step 3: The UE shall not automatically reattempt the request during the period duration T. 
Step 4: The UE reattempts to send a SUBSCRIBE request for registration event package. 

1 1 Notification 

11.1 Network- initiated deregistration 

11.1.1 Definition and applicability 

Test to verify that the UE can correctly process the network initiated deregistration request. 

11.1.2 Conformance requirement 

Upon receipt of a NOTIFY request on the dialog which was generated during subscription to the reg event package as 
described in subclause 5.1.1.3, including one or more <registration> element(s) with the state attribute set to 
"terminated" and the event attribute set to "rejected" or "deactivated", the UE shall remove all registration details 
relating to these public user identities. In case of a "deactivated" event attribute, the UE shall start the initial registration 
procedure as described in subclause 5.1.1.2. In case of a "rejected" event attribute, the UE shall release all dialogs 
related to those public user identities. 

Upon receipt of a NOTIFY request with all <registration> element(s) having their state attribute set to "terminated" (i.e. 
all public user identities are deregistered) and the Subscription-State header contains the value of "terminated", the UE 
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shall delete the security associations towards the P-CSCF after the server transaction (as defined in RFC 3261) 
pertaining to the NOTIFY request terminates. 

NOTE 1 : Deleting a security association is an internal procedure of the UE and does not involve any SIP 
procedures. 

NOTE 2: If the security association towards the P-CSCF is removed, then the UE considers the subscription to the 
reg event package terminated (i.e. as if the UE had sent a SUBSCRIBE request with an Expires header 
containing a value of zero, or a NOTIFY request was received with Subscription-State header containing 
the value of "terminated"). 

NOTE 3: When the P-CSCF has removed the security association established between the P-CSCF and the UE, 
further SIP signalling (e.g. the NOTIFY containing the deregistration event) will not reach the UE. 

Reference(s) 

3GPPTS 24.229[10], clauses 5.1.1.7 

11.1.3 Test purpose 

To verify that UE will not try registration after getting a NOTIFY with all <registration> element(s) set to "terminated" 
and "rejected". 

11.1.4 Method of test 

Initial conditions 

UE contains either ISIM and USIM applications or only USIM application on UICC. UE has activated a PDP context, 
discovered P-CSCF and registered to IMS services by executing the generic test procedure in Annex C.2 up to the last 
step.. 

SS is configured with the IMSI within the USIM application, the home domain name, public and private user identities 
together with the shared secret key of IMS AKA algorithm, related to the IMS private user identity (IMPI) that is 
configured on the UICC card equipped into the UE. SS is able to perform AKAvl-MD5 authentication algorithm for 
that IMPI, according to 3GPP TS 33.203 [14] clause 6.1 and RFC 3310 [17]. 

Related ICS/IXIT Statement(s) 



Test procedure 

1) SS sends UE a NOTIFY request for the subscribed registration event package, indicating that registration for all 
the previously registered user identities has been terminated and that new registration shall not be performed. 
Request is sent over the existing security associations between SS and UE. 

2) SS waits for the UE to respond the NOTIFY with 200 OK response. 
Expected sequence 



Step 


Direction 


lUlessage 


Comment 


UE 1 SS 


1 


^ 


NOTIFY 


The SS sends a NOTIFY for registration event 
package, containing full registration state 
information, with all previously registered public 
user identities "terminated" and "rejected" 


2 


■^ 


200 OK 


The UE responds the NOTIFY with 200 OK 
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Specific Message Contents 

NOTIFY (Step 1) 

Use the default message 'NOTIFY for reg-event package' in annex A. 1.6 with the following exceptions: 



Header/param 


Value/remark 


CSeq 

value 


2 


Subscription-State 

substate-value 
expires 


terminated 



Message-body 


<?xml version='1 .0?> 

<reginfo xmlns='um:ietf:params:xml:ns:reginfo' version='1 ' state='full'> 
<registration ao/'='px_PublicUserldentity' icl='a100' state='terminated'> 
<contact id='980' state='terminated' event='rejected'> 
<uri>same value as in Contact header of REGISTER request </ur/> 
</contact> 
</registration> 

<registration ao/'='px_AssociatedTelUri' id='a101' state='terminated'> 
<contact id='981' state='terminated' event='rejected'> 
<uri>same value as in Contact header of REGISTER request </ur/> 
</contact> 
</registration> 
</reginfo> 



200 OK for NOTIFY (Step 2) 

Use the default message '200 OK for other requests than REGISTER or SUBSCRIBE' in annex A.3.1 

11.1.5 Test requirements 

Step 2: SS shall check that the UE sends the 200 OK response over the existing set of security associations. 

SS shall check that terminal does not try to send a REGISTER message after sending 200 OK. Waiting period of one 
minute is sufficient. 

1 1 .2 Network initiated re-authentication 

1 1 .2.1 Definition and applicability 

Test to verify that the UE can correctly process the network initiated re-authentication request and re-authenticate the 
user before the registration expires, in accordance to 3GPP TS 24.229 [10], clause 5.1.1.5.2. 

1 1 .2.2 Conformance requirement 

At any time, the UE can receive a NOTIFY request carrying information related to the reg event package (as described 
in subclause 5.1.1.3). If: 

the state attribute in any of the <registration> elements is set to "active"; 

the value of the <uri> sub-element inside the <contact> sub-element is set to the Contact address that the UE 
registered; and 

the event attribute of that <contact> sub-element(s) is set to "shortened"; 

the UE shall: 

1) use the expiry attribute within the <contact> element to adjust the expiration time for that public user identity; 
and 
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2) start the re-authentication procedures at the appropriate time (as a resuh of the S-CSCF procedure described in 
subclause 5.4.1.6) by initiating a reregistration as described in subclause 5.1.1.4. 

Reference(s) 

3GPPTS 24.229 [10], clause 5.1.1.5.2 

11.2.3 Test purpose 

1) To verify that UE adjusts the expiration time for a public user identity as indicated within the received NOTIFY 
related to reg event package; and 

2) To verify that the UE will start the re-authentication procedures at the appropriate time before the registration 
expires. 

1 1 .2.4 Method of test 

Initial conditions 

UE contains either ISIM and USIM applications or only USIM application on UICC. UE has activated a PDP context, 
discovered P-CSCF and registered to IMS services by executing the generic test procedure in Annex C.2 up to the last 
step.. The expiration time for the registration (as controlled by px_RegisterExpiration) must be at least 600 seconds. 
Security associations have been set up between UE and the SS. 

SS is configured with the IMSI within the USIM application, the home domain name, public and private user identities 
together with the shared secret key of IMS AKA algorithm, related to the IMS private user identity (IMPI) that is 
configured on the UICC card equipped into the UE. SS is able to perform AKAvl-MD5 authentication algorithm for 
that IMPI, according to 3GPP TS 33.203 [14] clause 6.1 and RFC 3310 [17]. 

Related ICS/IXIT Statement(s) 



Test procedure 

1) SS sends UE a NOTIFY request for the subscribed registration event package, indicating the shortened 
expiration time as 60 seconds. Request is sent over the existing security associations between SS and UE. 

2) SS waits for the UE to respond the NOTIFY with 200 OK response. 

3) SS waits for the UE send a REGISTER request 30 seconds before the expected new expiration time. 

4) SS responds to the REGISTER request with a valid 401 Unauthorized response, headers populated according to 
the 401 response common message definition. 

5) SS waits for the UE to set up a new set of security associations and send another REGISTER request, over those 
security associations. 

6) SS responds to the REGISTER request with valid 200 OK response sent over the newly set up security 
associations 
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Expected sequence 



Step 


Direction 


lUlessage 


Comment 


UE 1 SS 


1 


-^ 


NOTIFY 


The SS sends a NOTIFY for registration event 
package, containing partial registration state 
information, indicating shortened expiration time (60 
seconds) for the registered public user identity in 
the XML body 


2 


-^ 


200 OK 


The UE responds the NOTIFY with 200 OK 


3 


-> 


REGISTER 


UE re-registers the user 30 seconds before the 
expected expiration 


4 


<- 


401 Unauthorized 


The SS responds with a valid AKAv1-MD5 
authentication challenge and security mechanisms 
supported by the network 


5 


■^ 


REGISTER 


UE completes the security negotiation procedures, 
sets up a new temporary set of SAs and uses 
those for sending another REGISTER with AKAv1 - 
IVIDS credentials. 


6 


<- 


200 OK 


The SS responds with 200 OK to complete the re- 
authentication.. 



Specific Message Contents 

NOTIFY (Step 1) 

Use the default message 'NOTIFY for reg-event package' in annex A. 1 .6 with the following exceptions: 



Header/param 



Value/remark 



CSeq 

value 



IVIessage-body 



<?xml version='1.0?> 

<reginfo xmlns='um:ietf:params:xml:ns:reginfo' version='1 ' state='partial'> 
<registration ao/'='px_PublicUserldentity' id='a100' state='active'> 
<contact icl='980' state=' active' event='shortened' expires="60"> 
<uri>same value as in Contact header of REGISTER request </uri> 
</contact> 
</registration> 
</reginfo> 
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200 OK for NOTIFY (Step 2) 

Use the default message '200 OK for other requests than REGISTER or SUBSCRIBE' in annex A.3.1 

REGISTER (Step 3) 

Use the default message 'REGISTER' in annex A. 1.1 condition A2 with the following exceptions: 



Header/param 



Value/remark 



CSeq 

value 



sequence number Incremented by one compared to the previous REGISTER 



Security-Client 

spi-c 
spi-s 
port-c 
port-s 



new SPI number of the inbound SA at the protected client port 

new SPI number of the inbound SA at the protected server port 

new protected client port needed for the setup of new pairs of security associations 

Same value as in the previous REGISTER 



401 Unauthorized for REGISTER (Step 4) 

Use the default message '401 Unauthorized for REGISTER' in annex A. 1.2 with the following exceptions: 



Header/param 


Value/remark 


Security-Server 

spi-c 
spi-s 
port-c 
port-s 


new SPI number of the inbound SA at the protected client port 

new SPI number of the inbound SA at the protected server port 

new protected client port needed for the setup of new pairs of security associations 

Same value as in the previous Security-Server headers 


www-Authenticate 

nonce 


Base 64 encoding of a new RAND and AUTN 



REGISTER (Step 5) 

Use the default message 'REGISTER' in annex A. 1.1 with condition A2 and the following exceptions: 



Header/param 


Value/remark 


CSeq 

value 


sequence number incremented by one compared to the previous REGISTER 
request 



200 OK for REGISTER (Step 6) 

Use the default message '200 OK for REGISTER' in annex A. 1.3 

1 1 .2.5 Test requirements 

Step 2: SS shall check that the UE sends the 200 OK response over the existing set of security associations. 

Step 3: SS shall check that in accordance to the 3GPP TS 24.229 [10] clause 5.1.1.4 the UE sends a REGISTER request 
over the existing set of security associations. 
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12 Call Control 

12.1 MO Call Successful 

12.1.1 Definition and applicability 

Test to verify that the UE correctly performs IMS mobile originated call setup and release. This process is described in 
3GPPTS 24.229 [10], clauses 5.1.3 and 6.1. 

12.1.2 Conformance requirement 

When the UE sends any request, the UE shall: 

include the protected server port in the Via header entry relating to the UE; and 
include the protected server port in any Contact header that is otherwise included. 



The UE shall insert a P-Access-Network-Info header into any request for a dialog, any subsequent request 
(except ACK requests and CANCEL requests) or response (except CANCEL responses) within a dialog or any 
request for a standalone method. This header shall contain information concerning the access network 
technology and, if applicable, the cell ID (see subclause 7.2A.4 of TS 24.229). 

The UE shall build a proper preloaded Route header value for all new dialogs and standalone transactions. The 
UE shall build a list of Route header values made out of, in this order, the P-CSCF URI (containing the IP 
address or the FQDN learnt through the P-CSCF discovery procedures, and the protected port learnt during the 
registration procedure), and the values received in the Service-Route header saved from the 200 (OK) response 
to the last registration or re-registration. 

Upon generating an initial INVITE request, the UE shall: 

indicate the support for reliable provisional responses and specify it using the Supported header mechanism; 

indicate the requirement of precondition and specify it using the Require header mechanism. 



When a final answer is received for one of the early dialogues, the UE proceeds to set up the SIP session. 
Usage of SDP by the UE: 

1) In order to authorize the media streams, the P-CSCF and S-CSCF have to be able to inspect the SDP 
payloads. Hence, the UE shall not encrypt the SDP payloads. 

2) An INVITE request generated by a UE shall contain SDP payload. The SDP payload shall reflect the calling 
user's terminal capabilities and user preferences for the session. The UE shall order the SDP payload with the 
most preferred codec listed first. In addition, the calling user shall indicate the desired QoS for the session, 
using the segmented status type. In an initial INVITE request the UE shall indicate that it mandates local QoS 
and that this precondition is not yet satisfied, i.e. the UE shall include the following preconditions: 

a=des: qos mandatory local sendrecv 

a=curr: qos local none 

3) Providing that the INVITE request received by the UE contains an SDP offer including one or more "m=" 
media descriptions, the first 183 (Session Progress) provisional response that the UE sends, shall contain the 
answer for the SDP received in the INVITE. The said SDP answer shall reflect the called user's terminal 
capabilities and user preferences. 
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4) When the UE sends a 183 (Session Progress) response with SDP payload including one or more "m=" media 
descriptions, it shall request confirmation for the result of the resource reservation at the originating end 
point. 

5) During session establishment procedure, SIP messages shall only contain SDP payload if that is intended to 
modify the session description. 

6) For "video" and "audio" media types that utilize the RTP/RTCP, the UE shall specify the proposed 
bandwidth for each media stream utilizing the "b=" media descriptor and the "AS" bandwidth modifier in the 
SDP. 

If the media line in the SDP indicates the usage of RTP/RTCP, in addition to the "AS" bandwidth modifier in 
the media-level "b=" line, the UE shall include two media-level "b=" lines, one with the "RS" bandwidth 
modifier and the other with the "RR" bandwidth modifier as described in RFC 3556 to specify the required 
bandwidth allocation for RTCP. 

For other media streams the "b=" media descriptor may be included. The value or absence of the "b=" 
parameter will affect the assigned QoS which is defined in 3GPP TS 29.208. 

NOTE 1 : In a two-party session where both participants are active, the RTCP receiver reports are not sent, 
therefore, the RR bandwidth modifer will typically get the value of zero. 

7) The UE shall include the MIME subtype "telephone-event" in the "m=" media descriptor in the SDP for 
audio media flows that support both audio codec and DTMF payloads in RTP packets as described in 
RFC 2833. 

Reference(s) 

3GPPTS 24.229[10], clauses 5.1.2A.1, 5.1.3 and 6.1 



12.1.3 Test purpose 



1) To verify that when initiating MO call the UE performs correct exchange of SIP protocol signalling messages 
for setting up the session; and 

2) To verify that within SIP signalling the UE performs the correct exchange of SDP messages for negotiating 
media and indicating preconditions for resource reservation (as described by 3GPP TS 24.229 [10], clause 6.1). 

3) To verify that the UE is able to release the call. 

12.1.4 Method of test 

Initial conditions 

UE contains either ISIM and USIM applications or only USIM application on UICC. UE has activated a PDP context, 
discovered P-CSCF and registered to IMS services, by executing the generic test procedure in Annex C.2 up to the last 
step. 

SS is configured with the shared secret key of IMS AKA algorithm, related to the IMS private user identity (IMPI) 
configured on the UICC card equipped into the UE. SS has performed AKAvl-MD5 authentication with the UE and 
accepted the registration. 

Related ICS/IXIT Statement(s) 

Support for initiating a session (Yes/No) 
Support for use of preconditions (Yes/No) 

Test procedure 

1) MO call is initiated on the UE. SS waits the UE to send an INVITE request with first SDP offer, over the 
security associations set up during registration, in accordance to 3GPP TS 24.229 [10], clause 5.1.3 
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2) SS responds to the INVITE request with a 100 Trying response. 

3) SS responds to the INVITE request with a 183 Session in Progress response 

NOTE: SS is not expected to take care of the media, so the IP address and port could be assigned so that the SS is 
listening to it, but may discard the RTP packets received. 

4) SS waits for the UE to send a PRACK request possibly containing the second SDP offer. 

5) SS responds to the PRACK request with valid 200 OK response. 

6) SS waits for the UE to optionally send a UPDATE request containing the final SDP offer. UE will not send the 
UPDATE request if PRACK request of step 4 already contained the final offer with preconditions met. 

7) SS responds to the UPDATE request (if UE sent one) with valid 200 OK response. 

8) SS responds to the INVITE request with 180 Ringing response. 

9) SS waits for the UE to send a PRACK request. 

10) SS responds to the PRACK request with valid 200 OK response. 
1 1. SS responds to the INVITE request with valid 200 OK response. 

12) SS waits for the UE to send an ACK to acknowledge receipt of the 200 OK for INVITE. 
13) Call is released on the UE. SS waits the UE to send a BYE request. 
14) SS responds to the BYE request with valid 200 OK response. 
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Expected sequence 



Step 


Direction 


lUlessage 


Comment 


UE 1 SS 


1 


^ 


INVITE 


UE sends INVITE with the first SDP offer indicating 
all desired medias and codecs the UE supports 


2 


-^ 


100 Trying 


The SS responds with a 100 Trying provisional 
response 


3 


-e 


183 Session in Progress 


The SS responds with an SDP answer indicating 
the medias and codecs acceptable for SS 


4 


^ 


PRACK 


UE acknowledges the receipt of 183 response with 
PRACK and offers second SDP that indicates one 
agreed codec per media and possibly indicates 
preconditions as met after having reserved the 
resources with GPRS 


5 


-^ 


200 OK 


The SS responds PRACK with 200 OK and 
answers the second SDP with mirroring its contents 
and indicates having reserved the resources if UE 
has also done so. 


6 


■^ 


UPDATE 


Optional step: UE sends an UPDATE after having 
reserved the resources with GPRS procedures for 
PDP context used for the media 


7 


-^ 


200 OK 


Optional step : The SS responds UPDATE with 200 
OK and indicates having reserved the resourced for 
the virtual remote UE 


8 


-^ 


180 Ringing 


The SS responds INVITE with 180 Ringing to 
indicate that the virtual remote UE has started 
ringing 


9 


■^ 


PRACK 


UE acknowledges the receipt of 180 response by 
sending PRACK 


10 


-^ 


200 OK 


The SS responds PRACK with 200 OK 


11 


-^ 


200 OK 


The SS responds INVITE with 200 OK to indicate 
that the virtual remote UE had answered the call 


12 


-^ 


ACK 


The UE acknowledges the receipt of 200 OK for 
INVITE 


13 


-^ 


BYE 


The UE releases the call with BYE 


14 


f- 


200 OK 


The SS sends 200 OK for BYE 



Specific Message Contents 

INVITE (Step 1) 

Use the default message 'INVITE for MO call setup' in annex A.2.1 For the contents of SDP body see test requirement 
details. 

100 Trying for INVITE (Step 2) 

Use the default message '100 Trying for INVITE' in annex A. 2. 2 

183 Session in Progress for INVITE (Step 3) 

Use the default message '183 Session in Progress for INVITE' in annex A.2.3 
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PRACK (Step 4) 

Use the default message 'PRACK' in annex A. 2. 4 



200 OK for PRACK (Step 5) 

Use the default message "200 OK for other requests than REGISTER or SUBSCRIBE" in annex A.3.1 with the 
following exceptions: 



Header/param 



Value/remark 



Content-Type 

media-type 



header shall be present only if there is SDP in message-body 
application/sdp 



Content-Length 

value 



length of message-body 



Message-body 



SDP body of the 200 response copied from the received PRACK, if it contained one 
but otherwise omitted. The copied SDP body must be modified as follows for the 
200 OK response: 

- IP address on "o=" and "c=" lines and transport port on "m=" lines changed to 
indicate to which IP address and port the UE should start sending the media; and 

optional "a=sendonly" line inverted to "a=recvonly" and vice versa; and 

- the "a=" lines describing the current and desired state of the preconditions, as 
described in RFC 3312 [31], updated as follows: 

a=curr:qos local [direction-tag] (1 
a=curr:qos remote [direction-tag] (2 
a=des:qos mandatory local [direction-tag] (3 
a=des:qos mandatory remote [direction-tag] (3 
a=conf:qos remote [direction-tag] (4 



1 ) The value of direction-tag In a=curr qos local line of of 200 must be the inverse of 
that in the a=curr:qos local line of PRACK. If the PRACK contained the direction-tag 
as "recv" the 200 must have it as "send" and vice versa. The values "none" and 
"sendrecv" will be kept as is. 

2) The value of direction-tag in a=curr qos remote line of 200 must be the inverse 
from the a=curr:qos local line of PRACK. 

3) The value of direction-tags in a=des lines of 200 must be the inverse from those 
of PRACK (both a= lines for local and remote). If the PRACK contained the 
direction-tag as "recv" the 200 must have it as "send" and vice versa. The value 
"sendrecv" will be kept as is. 

4) The value of direction-tag for the optional line conf:qos remote shall be the same 
as for des: qos mandatory remote. This line is only included if a=curr:qos remote is 
still "none". 
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UPDATE (Step 6) optional step used when PRACK contained a=curr:qos local none 
Use the default message 'UPDATE' in annex A. 2. 5 

200 OK for UPDATE (Step 7) - optional step used when UE sent UPDATE 

Use the default message '200 OK for other requests than REGISTER or SUBSCRIBE' in annex A.3. 1 with the 
following exceptions: 



Header/param 


Value/remark 


Content-Type 

media-type 


application/sdp 


Content-Length 

value 


length of message-body 


Message-body 


SDP body of the 200 response copied from the received UPDATE but modified as 
follows: 

- IP address on "o=" and "c=" lines and transport port on "m=" lines changed to 
indicate to which IP address and port the UE should start sending the media; and 

optional "a=sendonly" line inverted to "a=recvonly" and vice versa; and 

- the "a=" lines describing the current and desired state of the preconditions, as 
described in RFC 3312 [31], updated as follows: 

a=curr:qos local [direction-tag] (1 
a=curr:qos remote [direction-tag] (2 
a=des:qos mandatory local [direction-tag] (3 
a=des:qos mandatory remote [direction-tag] (3 

1 ) The value of direction-tag in a=curr qos local line of 200 must be the inverse of 
that in the a=curr:qos local line of UPDATE. If the UPDATE contained the direction- 
tag as "recv" the 200 must have it as "send" and vice versa. The value "sendrecv" 
will be kept as is. 

2) The value of direction-tag in a=curr qos remote line of 200 must be the inverse 
from the a=curr:qos local line of UPDATE. 

3) The value of direction-tags in a=des lines of 200 must be the inverse from those 
of UPDATE (both a= lines for local and remote). If the UPDATE contained the 
direction-tag as "recv" the 200 must have it as "send" and vice versa. The value 
"sendrecv" will be kept as is. 
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180 Ringing for INVITE (Step 8) 

Use the default message '180 Ringing for INVITE' in annex A. 2. 6 

PRACK (Step 9) 

Use the default message 'PRACK' in annex A. 2. 4 

200 OK for PRACK (Step 1 0) 

Use the default message '200 OK for other requests than REGISTER or SUBSCRIBE' in annex A.3.1. 

200 OK for INVITE (Step 11) 

Use the default message '200 OK for other requests than REGISTER or SUBSCRIBE' in annex A.3. 1 with the 
following exceptions: 



Header/param 


Value/remark 


Record-Route 

rec-route 


Same value as in the 180 response 


Contact 

addr-spec 


Same value as in the 180 response 



ACK(Step12) 

Use the default message 'ACK' in annex A.2.7 

BYE (Step 13) 

Use the default message 'BYE' in annex A. 2. 8 

200 OK for BYE (Step 14) 

Use the default message '200 OK for other requests than REGISTER or SUBSCRIBE' in annex A.3.1. 

12.1.5 Test requirements 

SS must check that the UE sends all the requests over the security associations set up during registration, in accordance 
to 3GPP TS 24.229 [10], clause 5.1.1.5.1. 

Step 1: the UE shall send an INVITE message with correct content. The UE shall include the following lines in the SDP 
body: 

All mandatory SDP lines, as specified in SDP grammar in RFC 2327 [27] appendix A, including: 

"o=" line indicating e.g. the session identifier and the IP address of the UE; 

"c=" line indicating the IP address of the UE for receiving the media flow; 

Media description lines for the media proposed by UE for the MO call. For each type of offered media the 
following lines must exist within the SDP: 

"m=" line describing the media type, transport port and protocol used for media and media format; 

"b=" line proposing the application specific maximum bandwidth ("AS" modifier) for the media , however 
this line maybe missing if the SDP contains "a=sendonly" line, according to RFC 3264 [30]; 

optionally two "b=" lines proposing the bandwidth allocations for RTCP (for "RS" and "RR" modifiers), if 
the media line in the SDP indicates the usage of RTP/RTCP, as described in RFC 3556; 

extra "a=" line for rtpmap attribute per each dynamic payload type given in the "m=" line: 
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If the UE supports DTMF payloads in RTP packets for audio type of media, then one of the "a=" lines 
shall indicate "telephone-event" MIME subtype; 

Any of the "a=" line for rtpmap attribute may be followed by extra "a=" line for fmtp attribute to convey 
parameters specific to a particular format; 

four "a=" lines describing the current and desired state of the preconditions, as described in RFC 3312 [31]. 

At this stage of the call setup the lines shall be as follows: 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local [send, recv or sendrecv] 

a=des:qos [none optional or mandatory] remote [send, recv or sendrecv]s 

The direction tag for remote shall be the same as for local 



Step 4: the UE shall send a PRACK request with the correct content. The UE may include a SDP body in the PRACK 
request if SDP body of INVITE offered multiple codecs per media. In that case the following lines shall be included in 
the SDP body of PRACK: 

All mandatory SDP lines, like in INVITE request except the version number in the 'o' line incremented by one; 
and 

All media description lines as in the INVITE and the order of those lines preserved. The permitted changes to the 
media description lines and media dependent attribute lines are as described in RFC 3264 [30] and include e.g. 
the following: 

New media lines (if any) shall be added after the media lines introduced within the INVITE. 

Media lines dropped in the offer/answer negotiation indicated by port number changed as zero. Any attribute 
lines related to dropped media may have been removed. 

Address, port or transport, media types, formats or attributes of original media lines may have been modified. 

Optional new "a=" lines may be introduced that the SS shall ignore - The "a=" lines for preconditions in the 
PRACK shall be like for INVITE in step 1 but with the following exceptions: 

in attribute line a=curr:qos local the direction-tag may have either the value "none" or the same value that 
the direction-tag has in the attribute line a=des:qos mandatory local. The latter case indicates that the UE 
has already met its local preconditions. 

in attribute line a=des:qos [strength-tag] remote [direction-tag] the strength-tag must be "mandatory" 
(according to what SS answered in 183 response) 



Step 6: the UE may conditionally send an UPDATE request with the correct content. The UE shall include the 
following lines in the SDP body: 

All mandatory SDP lines, like in INVITE request except the version number in the 'o' line incremented by two; 
and 

All media description lines as in the INVITE and the order of those lines preserved. The permitted changes to the 
media description lines and media dependent attribute lines are as described in RFC 3264 [30] 

Optional new "a=" lines may be introduced that the SS shall ignore 

The "a=" lines for preconditions in the UPDATE shall be like for INVITE in step 1 but with the following 
exceptions: 

in attribute line a=curr:qos local the direction-tag must have the same value that the direction-tag has in the 
attribute line a=des:qos mandatory local, to indicate that the UE has met its local preconditions. 

in attribute line a=des:qos [strength-tag] remote [direction-tag] the strength-tag must be "mandatory" 
(according to what SS answered in 183 response) 
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Step 9: the UE shall send a PRACK request with the correct content, according to common message definitions. 

Step 12: the UE shall send an ACK request with the correct content, according to common message definitions. 
Step 13: the UE shall send a BYE request with the correct content, according to common message definitions. 

1 2.2 MO Call - 503 Service Unavailable 

12.2.1 Definition 

When a server is temporarily unable to process an INVITE request due to a temporary overloading or maintenance of 
the server sends a 503 Service Unavailable response. The server may indicate when the service will be available again 
in a Retry- After header field. This process is described in 3GPP TS 24.229 [10], clause 5.1.3.1. 

12.2.2 Conformance requirement 

If the UA receives a 503 (Service Unavailable) response to an initial INVITE request containing a Retry- After header, 
then the UE shall not automatically reattempt the request until after the period indicated by the Retry- After header 
contents. 

Reference(s) 

3GPPTS 24.229[10], clause 5.1.3.1 

12.2.3 Test purpose 

To verify that when the UE receives a 503 (Service Unavailable) response to an initial INVITE request containing a 
Retry- After header, then the UE shall not automatically reattempt the request until after the period indicated by the 
Retry-After header contents. 

12.2.4 Method of test 

Initial conditions 

UE contains either ISIM and USIM applications or only USIM application on UICC. UE has activated a PDP context, 
discovered P-CSCF and registered to IMS services, by executing the generic test procedure in Annex C.2 up to the last 
step. 

SS is configured with the shared secret key of IMS AKA algorithm, related to the IMS private user identity (IMPI) 
configured on the UICC card equipped into the UE. SS has performed AKAvl-MD5 authentication with the UE and 
accepted the registration. 

Related ICS/IXIT Statement(s) 

Test procedure 

For value of T see specific message content for 503 (Service Unavailable) message. 

1) MO call is initiated on the UE. SS waits for the UE to send an INVITE request with first SDP offer, over the 
security associations set up during registration, in accordance to 3GPP TS 24.229 [10], clause 5.1.3 

2) The SS responds with a provisional 100 (Trying) response to the INVITE request followed by a 503 (Service 
Unavailable) response with the Retry- After header set to T. 
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3) The SS waits for the UE to send an ACK to acknowledge the reception of the 503 (Service Unavailable) 
response. 

4) SS waits for a duration of time T and checks that the UE does not reattempt sending the INVITE request. After 
the time T the UE may reattempt sending the INVITE request. 

5) The UE may reattempt sending the INVITE request after time T. 
Expected sequence 



Step 


Direction 


Message 


Comment 


UE 1 SS 


1 


^ 


INVITE 


The UE sends an INVITE request with the first SDP 
offer indicating all desired medias and codecs the 
UE supports 


2a 


-e 


100 Trying 


The SS responds with a 100 Trying provisional 
response 


2b 


-^ 


503 Service Unavailable 


Including Retry-After header with period set to T 


3 


^ 


ACK 


The UE acknowledges the reception of the 503 
(Service Unavailable) response 


4 






The SS waits for a duration of time T and checks 
that the UE does not re-send the INVITE request 


5 


-> 


INVITE 


Optional 



Specific Message Contents 

INVITE (Step 1) 

Use the default message INVITE for MO call setup' in annex A. 

100 Trying (Step 2a) 

Use the default message '100 Trying for MO INVITE' in annex A. 

503 Service Unavailable (Step 2b) 



Header 


Value/remark 


Retry-After 






period 




eOsecs (referred to as T in the test procedure and test 
requirement) 


duration 




Not present 


comment 




Not present 



ACK (Step 3) 

Use the default message 'ACK' in annex A. 

INVITE (Step 4) 

Use the default message 'INVITE for MO call setup' in annex A. 

12.2.5 Test requirements 

At step 4 the UE shall not reattempt the INVITE request before time T from the time the SS receives the ACK from the 
UE in step 2b. 



£75/ 



3GPP TS 34.229-1 version 5.0.0 Release 5 93 ETSI TS 134 229-1 V5.0.0 (2006-06) 

1 2.3 MO Call - 488 Not Acceptable Here 

12.3.1 Definition 

When a UA has been contacted successfully but some aspects of the session description such as the requested media, 
bandwidth, or addressing style were not acceptable then the UA may send a 488 (Not Acceptable Here) response. A 
message body containing a description of media capabilities may be present in the response. This process is described in 
3GPP TS 24.229 [10], clauses 5.1.3.1 and 6.1. 

12.3.2 Conformance requirement 

If the UE receives a 488 (Not Acceptable Here) response to an initial INVITE request, the UE should send a new 
INVITE request containing SDP according to the procedures defined in subclause 6. 1 of 24.229. 

Usage of SDP by the UE: 



10. If the UE builds SDP for an INVITE request generated after receiving a 488 (Not Acceptable Here) response, as 
described in subclause 5.1.3.1 of 24.229, the UE shall include SDP payload containing a subset of the allowed 
media types, codecs and other parameters from the SDP payload of all 488 (Not Acceptable Here) responses 
related to the same session establishment attempt (i.e. a set of INVITE requests used for the same session 
establishment). The UE shall order the codecs in the SDP payload according to the order of the codecs in the 
SDP payload of the 488 (Not Acceptable Here) response. 

NOTE 2: The UE may be attempting a session establishment through multiple networks with different policies and 
potentially may need to send multiple INVITE requests and receive multiple 488 (Not Acceptable Here) 
responses from different CSCF nodes. The UE therefore takes into account the SDP contents of all the 
488 (Not Acceptable Here) responses received related to the same session establishment when building a 
new INVITE request. 

Reference(s) 

3GPP TS 24.229[10], clauses 5.1.3.1 and 6.1 

12.3.3 Test purpose 

1) To verify that the UE includes SDP payload containing a subset of the allowed media types, codecs and other 
parameters from the SDP payload of the 488 (Not Acceptable Here) response. 

2) To verify that the UE orders the codecs in the SDP payload according to the order of the codecs in the SDP 
payload of the 488 (Not Acceptable Here) response. 

12.3.4 Method of test 

Initial conditions 

UE contains either ISIM and USIM applications or only USIM application on UICC. UE has activated a PDP context, 
discovered P-CSCF and registered to IMS services, by executing the generic test procedure in Annex C.2 up to the last 
step 

SS is configured with the shared secret key of IMS AKA algorithm, related to the IMS private user identity (IMPI) 
configured on the UICC card equipped into the UE. SS has performed AKAvl-MD5 authentication with the UE and 
accepted the registration. 

Related ICS/IXIT Statement(s) 

[UE supports sending of new INVITE request upon receiving a 488 (Not Acceptable Here) response] 
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UEs supporting more than one media 

Test procedure 

1) MO call is initiated on the UE. SS waits for the UE to send an INVITE request with first SDP offer, over the 
security associations set up during registration, in accordance to 3GPP TS 24.229 [10], clause 5.1.3 

2) The SS responds with a provisional 100 (Trying) response to the INVITE request followed by a 488 (Not 
Acceptable Here) response. The SS includes a SDP payload [TBD]. 

3) The SS waits for the UE to send an ACK to acknowledge the reception of the 488 (Not Acceptable Here) 
response. 

4) SS wait for the UE to send a new INVITE request. The SS checks that the SDP payload of the new INVITE 
request includes a subset of the allowed media types, codecs and other parameters from the SDP payload of the 
488 (Not Acceptable Here) response in step 2. 

Expected sequence 



Step 


Direction 


lUlessage 


Comment 


UE 1 SS 


1 


^ 


INVITE 


The UE sends an INVITE request with the first SDP 
offer indicating all desired medias and codecs the 
UE supports 


2a 


^ 


100 Trying 


The SS responds with a 100 Trying provisional 
response 


2b 


<- 


488 Not Acceptable Here 


The SS includes a SDP payload being a subset of 
the offer in the first SDP offer in step 1 . 


3 


■^ 


ACK 


The UE acknowledges the reception of the 488 (Not 
Acceptable Here) response 


4 


-> 


INVITE 


The UE sends a new INVITE request. 



Specific Message Contents 

INVITE (Step 1) 

Use the default message INVITE for MO call setup' in annex A. 

100 Trying (Step 2a) 

Use the default message '100 Trying for MO INVITE' in annex A. 

488 Not Acceptable Here (Step 2b) 



Header 


Value/remark 


SDP 


[FFS] 
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ACK (Step 3) 

Use the default message 'ACK' in annex A. 

INVITE (Step 4) 

Use the default message 'INVITE for MO call setup' in annex A. For the contents of SDP body see test requirement 
details. 

12.3.5 Test requirements 

1) At step 4 the SDP payload in the INVITE request shall include a SDP payload containing a subset of the allowed 
media types, codecs and other parameters from the SDP payload of the 488 (Not Acceptable Here) response in 
step 2b. 

2) At step 4 the codecs in the SDP payload in the INVITE request shall be in the same order as in the SDP payload 
of the 488 (Not Acceptable Here) response. 

12.4 Call initiation - Mobile termination 

12.4.1 Definition 

Test to verify that the UE can correctly receive a call initiation request and generate the correct response. This process is 
described in 3GPP TS 24.229 [10], clause 5.1.4.1 

12.4.2 Conformance requirement 

When the UE sends any response, the UE shall: 

include the protected server port in any Contact header that is otherwise included. 

The UE shall discard any SIP request that is not integrity protected and is received from the P-CSCF outside of the 
registration and authentication procedures. 

The UE can indicate privacy of the P-Asserted-Identity that will be generated by the P-CSCF in accordance with 
RFC 3323 and the additional requirements contained within RFC 3325 . 

The UE shall insert a P- Access-Network-Info header into any response to a request for a dialog, any subsequent request 
(except CANCEL requests) or response (except CANCEL responses) within a dialog or any response to a standalone 
method. This header shall contain information concerning the access network technology and, if applicable, the cell ID 



Upon receiving an initial INVITE request without containing either Supported: precondition or Require: precondition 
header values, the UE shall generate a 421 (Extension Required) response indicating the required extension in the 
Require header field. 

Upon generating the first response to the initial INVITE request, the UE shall indicate the requirement for reliable 
provisional responses and specify it using the Require header mechanism.The UE shall send the 200 (OK) response to 
the initial INVITE request only after the local resource reservation has been completed. 



In order to authorize the media streams, the P-CSCF and S-CSCF have to be able to inspect the SDP payloads. Hence, 
the UE shall not encrypt the SDP payloads. 

An INVITE request generated by a UE shall contain SDP payload. The SDP payload shall reflect the calling user's 
terminal capabilities and user preferences for the session. The UE shall order the SDP payload with the most preferred 
codec listed first. In addition, the calling user shall indicate the desired QoS for the session, using the segmented status 
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type. In an initial INVITE request the UE shall indicate that it mandates local QoS and that this precondition is not yet 
satisfied, i.e. the UE shall include the following preconditions: 

a=des: qos mandatory local sendrecv 

a=curr: qos local none 

Providing that the INVITE request received by the UE contains an SDP offer including one or more "m=" media 
descriptions, the first 183 (Session Progress) provisional response that the UE sends, shall contain the answer for the 
SDP received in the INVITE. The said SDP answer shall reflect the called user's terminal capabilities and user 
preferences. 

When the UE sends a 183 (Session Progress) response with SDP payload including one or more "m=" media 
descriptions, it shall request confirmation for the result of the resource reservation at the originating end point. 

During session establishment procedure, SIP messages shall only contain SDP payload if that is intended to modify the 
session description. 

For "video" and "audio" media types that utilize the RTP/RTCP, the UE shall specify the proposed bandwidth for each 
media stream utilizing the "b=" media descriptor and the "AS" bandwidth modifier in the SDP. 

If the media line in the SDP indicates the usage of RTP/RTCP, in addition to the "AS" bandwidth modifier in the 
media-level "b=" line, the UE shall include two media-level "b=" lines, one with the "RS" bandwidth modifier and the 
other with the "RR" bandwidth modifier as described in RFC 3556 to specify the required bandwidth allocation for 
RTCP. 

For other media streams the "b=" media descriptor may be included. The value or absence of the "b=" parameter will 
affect the assigned QoS which is defined in 3GPP TS 29.208. 

The UE shall include the MIME subtype "telephone-event" in the "m=" media descriptor in the SDP for audio media 
flows that support both audio codec and DTMF payloads in RTP packets as described in RFC 2833. 

The UE shall inspect the SDP contained in any SIP request or response, looking for possible indications of grouping of 
media streams according to RFC 3524 and perform the action outlined in subclause 9.2.5. 

Reference(s) 

3GPPTS 24.229 [10], clauses 5.1.2A.2, 5.1.4.1, 6.1 

12.4.3 Test purpose 

1) To verify that after receiving a valid INVITE for call initiation, the UE correctly generates and sends the first 
183 Session Progress response; and 

2) To verify that the UE includes the proper SDP answer to the SDP offer in the INVITE; and 

3) To verify that the UE inserts a P-Access-Network-Info header into any response to a request for a dialog, any 
subsequent request (except CANCEL requests) or response (except CANCEL responses) within a dialog or any 
response to a standalone method. This header shall contain information concerning the access network 
technology and, if applicable, the cell ID; and 

4) To verify that the UE includes the protected server port in any Contact header; and 

5) To verify that the UE does not encrypt the SDP payload; and 

6) To verify that the UE supports and handles the precondition extension properly 

7) To verify that the UE can release the call on receiving BYE from the SS 
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12.4.4 Method of test 

Initial conditions 

UE contains either ISIM and USIM applications or only USIM application on UICC. UE has activated a PDP context, 
discovered P-CSCF and registered to IMS services, by executing the generic test procedure in Annex C.2 up to the last 
step. 

SS is configured with the shared secret key of IMS AKA algorithm, related to the IMS private user identity (IMPI) 
configured on the UICC card equipped into the UE. SS has performed AKAvl-MD5 authentication with the UE and 
accepted the registration. 

Related ICS/IXIT Statement(s) 

<The SS is preconfigured to generate SDP offers that are compatible with the UE"s capabilities.> 

Test procedure 

1) SS sends an INVITE request to the UE. 

2) SS may receive 100 Trying from the UE. 

3) SS expects and receives 183 Session Progress from the UE. 

4) SS sends PRACK to the UE to acknowledge the 183 Session Progress. 

5) SS expects and receives 200OK for PRACK from the UE. 

6) SS sends UPDATE to the UE, with SDP indicating that precondition is met on the server side. 

7) SS expects and receives 200OK for UPDATE from the UE, with proper SDP as answer. 

8) SS expects and receives 180 Ringing from the UE. 

9) SS sends PRACK to the UE to acknowledge the 180 Ringing. 
10)SS expects and receives 200OK for PRACK from the UE. 

1 1)SS expects and receives 200OK for INVITE from the UE. 

12)SS sends ACK to the UE. 

13)SS sends BYE to the UE. 

14) SS expects and receives 200OK for BYE from the UE. 
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Expected sequence 



Step 


Direction 


lUlessage 


Comment 


UE 1 SS 


1 


-^ 


INVITE 


SS sends INVITE with the first SDP offer. 


2 


^ 


100 Trying 


(Optional) The UE responds with a 100 Trying 
provisional response 


3 


■^ 


183 Session Progress 


The UE sends 183 response reliably with the SDP 
answer to the offer in INVITE 


4 


<- 


PRACK 


SS acknowledges the receipt of 183 from the UE. 
No SDP offer is included here. 


5 


■^ 


200OK 


The UE responds to PRACK with 200OK. 


6 


^ 


UPDATE 


SS sends an UPDATE with a second SDP offer 
after having reserved the resources. 


7 


■^ 


200OK 


The UE acknowledges the UPDATE with 200OK 
and includes SDP answer to acknowledge its 
current precondition status. 


8 


■^ 


180 Ringing 


The UE responds to INVITE with 180 Ringing after 
its resource is ready. 


9 


<- 


PRACK 


The SS acknowledges the 180 response with 
PRACK. 


10 


■^ 


200OK 


The UE acknowledges the PRACK with 200OK. 


11 


■^ 


200OK 


The UE responds to INVITE with 200 OK final 
response after the user answers the call. 


12 


^ 


ACK 


The SS acknowledges the receipt of 200OK for 
INVITE. 


13 


«- 


BYE 


The SS sends BYE to release the call. 


14 


^ 


200OK 


The UE sends 200OK for the BYE request and 
ends the call. 
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Specific Message Content 



INVITE (Step 1) 

Same as the default message in subclause A.2.9 with the following exceptions: 



Headers to be included 



Value/Remark 



SDP 



The SDP contains all mandatory SDP lines, as specified in SDP 
grammar in RFC 2327[27], including: 

- 'v= 0' 

"o=" line indicating e.g. the session Identifier and the IP address 

of the SS; 

's=IIVIS conformance test' 

- 't=0 0' 

"c=" line indicating the IP address of the SS for receiving the 
media flow; 

The SDP includes one or more media description lines based on 
preconfigured information so that the SDP is compatible with the UE"s 
capabilities. 

For each type of offered media the following lines must exist within the 
SDP: 

"m=" line describing the media type, transport port and protocol 

used for media and media format; 

"b=" line proposing the application specific maximum bandwidth 

("AS" modifier) for the media; 

two "b=" lines proposing the bandwidth allocations for RTCP 

(for "RS" and "RR" modifiers), if the media line in the SDP 

indicates the usage of RTP/RTCP, as described in RFC 

3556[53]; 

extra "a=" line for rtpmap attribute per each dynamic payload 

type given in the "m=" line. 

Any of the "a=" line for rtpmap attribute may be followed by 

extra "a=" line for fmtp attribute to convey parameters specific 

to a particular format; 

For each offered media, the precondition shall be set as follows: 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local [direction-tag] (note 1) 

a=des:qos mandatory remote [direction-tag] (note 2) 

note 1 : The value of direction-tag may be sendrecv, send, or recv. It 

is preconfigured based on the UE"s capability. 
note 2: The value of direction-tag may be sendrecv, send, or recv. 



£75/ 



3GPP TS 34.229-1 version 5.0.0 Release 5 



100 



ETSI TS 134 229-1 V5.0.0 (2006-06) 



100 Trying (Step 2) 

Shall be formatted same as the default message in subclause A2.2. 

183 Session Progress (Step 3) 

Same as the default message in subclause A.2.3 with the following exceptions: 



Headers to be included 


Value/Remark 


Status-Line 

Reason-Phrase 


Not checked 


SDP 


Properly generated SDP answer to the SDP offer contained in the 
INVITE. 

For each media, the precondition attribute lines are set as follows: 

a=curr:qos local [direction-tag] (note 1) 

a=curr:qos remote none 

a=des:qos mandatory local [direction-tag] (note 2) 

a=des:qos mandatory remote [direction-tag] (note 3) 

a=conf:qos remote [direction-tag] (note 4) 

note 1 : The current qos status for local may be either none or the 

inverse of the desired remote value in Step 1 depending on whether 

the UE"s precondition status has been met. 

note 2: The inverse of the desired remote value in Step 1 . 

note 3: The inverse of the desired local value in Step 1. 

note 4: The inverse of the desired local value in Step 1 . 



PRACK (step 4) 

Shall be formatted as the default message in subclause A.2.4, but without 'Route' and 'P- Access-Network-Info' headers. 
No content body is included in the PRACK. 

200 OK (Step 5) 

Shall be formatted as the default message in subclause A.3.1 with following exceptions: 



Headers to be included 


Value/Remark 


P-Access-Network-lnfo 


same value as in 183 message 



UPDATE (step 6) 

Shall be the same as the default message in subclause A.2.5, but without including 'Route', 'Proxy-Require', 'Security- 
Verify', and 'P-Access-Network-Info' headers and with the following exceptions: 



Headers to be included 


Value/Remark 


SDP 


Same SDP offer as in INVITE with version number in the 'o' line 
incremented by one. 

For each media, the precondition attributes are set as follows: 
a=curr:qos local local [direction-tag] (note 1) 
a=curr:qos remote local [direction-tag] (note 2) 
a=des:qos mandatory local local [direction-tag] (note 3) 
a=des:qos mandatory remote local [direction-tag] (note 4) 

note 1 : The same value as the desired local value in Step 1 . 
note 2: The inverse of the current local value in Step 3. 
note 3: The same value as the desired local value in Step 1 . 
note 4: The same value as the desired remote value in Step 1 . 


Require 


Option tag 'sec-agree' is not included 
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200 OK (step 7) 

Shall be the same as the default message '200 OK' ' in subclause A. 3.1 with the following exceptions: 



Headers to be included 


Value/Remark 


SDP 


Same SDP answer as in 183 with version number in tlie 'o' line 
incremented by one. 

For each media, the precondition attributes are set as follows: 
a=curr:qos local [direction-tag] (note 1) 
a=curr:qos remote [direction-tag] (note 2) 
a=des:qos mandatory local [direction-tag] (note 3) 
a=des:qos mandatory remote [direction-tag] (note 4) 

note 1 : The current qos status for local may be either none or the 
same as the desired local value in Step 3 depending on whether the 
UE"s precondition status has been met. 
note 2: The same value as the desired remote value in Step 3. 
note 3: The same value as the desired local value in Step 3. 
note 4: The same value as the desired remote value in Step 3. 


P- Access-Network-Info 


same value as in 183 message 


Content-Type 


application/SDR 



180 Ringing (step 8) 

Shall be formatted as the default message in subclause A.2.6 without the 'Record-Route' header and with the following 
exceptions: 



Headers to be included 


Value/Remark 


Status-Line 

Reason-Phrase 


Not checked 


P- Access-Network-Info 


same value as in 183 message 


RSeq 

response-num 


the value in 183 incremented by one 



PRACK (step 9) 

Shall be formatted as the default message in subclause A.2.4, but without 'Route' and 'P-Access-Network-Info' headers. 
No content body is included in the PRACK. 

200 OK (step 1 0) 

Shall be formatted as the default message '200 OK' ' in subclause A. 3.1 with following exceptions: 



Headers to be included 


Value/Remark 


P-Access-Network-lnfo 


same value as in 183 message 



200 OK (step 1 1 ) 

Shall be formatted as the default message '200 OK in subclause A.3.1 with following exceptions: 



Headers to be included 


Value/Remark 


P- Access-Network-Info 


same value as in 183 message 


Record-Route 


same value as in INVITE message 
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ACK(step12) 

Shall be formatted the same as the default message in subclause A.2.7 without the 'Route' header. 

BYE (Step 13) 

Shall be formatted the same as the default message in subclause A.2.8 without 'Require', 'Proxy-Require', 'Route', 
'Security- Verify', and 'P-Access-Network-Info' headers. 

200 OK (Step 14) 

Shall be formatted the same as the default message in subclause A.3.1 with following exceptions: 



Headers to be included 


Value/Remark 


P- Access-Network-Info 


same value as in 183 message 



12.4.5 Test requirements 

The UE shall send requests and responses described in subclause 12.4. over the security association established during 
the registration/authentication process. The UE shall also include the P-Access-Network-Info header in these messages. 
If the UE includes Contact header in the request or response, it shall include the protected server port in the Contact 
header. In addition, if there is SDP content in the SIP message body, the UE shall not encrypt the SDP content. 

In step 2, if 100 Trying is sent, the UE shall populate the headers as defined in subclause 12.4.4. 

In step 3, the UE shall populate the headers as defined in subclause 12.4.4, and: 

1) The UE shall include the answer for the SDP offer in the INVITE. The SDP answer indicates that the UE 
supports the media type and MIME type offered by the SS. 

2) The UE shall request confirmation for the result of the resource reservation at the originating end point. The 
precondition related SDP lines are verified as described in subclause 12.4.4. 

In step 5, the UE shall populate the headers as defined in subclause 12.4.4. 

In step 7, the UE shall populate the headers as defined in subclause 12.4.4 and 

- the UE indicates in the SDP answer the precondition status on both ends as described in subclause 12.4.4. 

In step 8, the UE shall populate the headers as defined in subclause 12.4.4. 

In step 10, the UE shall populate the headers as defined in subclause 12.4.4. 

In step 11, the UE shall populate the headers as defined in subclause 12.4.4. 

In step 14, the UE shall populate the headers as defined in subclause 12.4.4. 

The SS shall check in step 8) that in accordance to the 3GPP TS 24.229[10], the headers covered in the specific 

message 

13 Signalling Compression (SIGComp) 

13.1 SigComp in the Initial registration 
13.1.1 Definition and applicability 

Test to verify that the UE can correctly register to IMS services when the P-CSCF supports and uses SigComp. The 
process consists of sending initial registration by the UE to S-CSCF via the P-CSCF with SIP Compression enabled and 
support of SIP Compression indicated by 'comp=sigcomp'. 
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13.1.2 Conformance requirement 



The UE shall support SigComp as specified in RFC 3320. When using SigComp the UE shall send compressed SIP 
messages in accordance with RFC 3486. 



The UE shall support the SIP dictionary specified in RFC 3485. If compression is enabled, the UE shall use the 
dictionary to compress the first message. 



The UE shall decompress the compressed requests and responses received from the P-CSCF according to 
subclause 8.1.1. 

Reference(s) 

3GPPTS 24.229 [10], clauses 8.1.1, 8.1.2, and 8.1.3. 

13.1.3 Test purpose 

1) To verify that the UE sends a initial REGISTER request, which announces to support SIP Compression 
'comp=sigcomp', to S-CSCF via the discovered P-CSCF, according to 3GPP TS 24.229 [10] clause 8.1.1; and 

2) To verify that the UE sends a compressed initial REGISTER request to S-CSCF via the discovered P-CSCF, 
according to 3GPP TS 24.229 [10] clause 8.1.1 if the UE is capable to compress the first REGISTER message; 
and 

3) To verify that after receiving a valid 401 (Unauthorized) response from S-CSCF for the initial REGISTER sent, 
the UE sends a compressed initial REGISTER request, which announces to support SIP Compression 
'comp=sigcomp', to S-CSCF via the discovered P-CSCF, according to 3GPP TS 24.229 [10] clause 8.1.1 if the 
UE is capable to compress upon receiving the first compressed message; and 

4) To verify that after receiving a valid NOTIFY request from S-CSCF, which announces to support SIP 
Compression 'comp=sigcomp' parameter in the Via header the UE sends a compressed 200 OK response; and 

5) To verify that the UE sends the compressed initial REGISTER in accordance with SIP dictionary specified in 
RFC 3485 [25] if the UE is capable to compress the first REGISTER message; and 

6) To verify that the UE sends the compressed second REGISTER in accordance with SIP dictionary specified in 
RFC 3485 [25] if the UE is capable to compress upon receiving the first compressed message; and?) To verify 
that the UE sends the compressed 200 OK response to NOTIFY in accordance with SIP dictionary specified in 
RFC 3485 [25] in the case the UE is not capable to compress the first REGISTER message or is not capable to 
compress upon receiving the first compressed message; and 

7) To verify that UE decompress all the SIP messages sent by the SS in accordance 3GPP TS 24.229 [10] clause 
8.1.1. 

13.1.4 Method of test 

Initial conditions 

UE contains either ISIM and USIM applications or only USIM application on UICC. UE is not registered to IMS 
services, but has an active PDP context and has discovered the SS as P-CSCF by executing the generic test procedure in 
Annex C.2 up to step 3.SS is configured with the IMSI within the USIM application, the home domain name, public 
and private user identities together with the shared secret key of IMS AKA algorithm, related to the IMS private user 
identity (IMPI) that is configured on the UICC card equipped into the UE. SS is listening to SIP default port 5060 for 
both UDP and TCP protocols. SS is able to perform AKAvl-MD5 authentication algorithm for that IMPI, according to 
3GPPTS 33.203 [14] clause 6.1 and RFC 3310 [17]. 
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Related ICS/IXIT Statement(s) 

UE compresses the initial REGISTER message (Yes/No) 

UE compresses upon receiving the first compressed message (Yes/No) 

Test procedure 

1) IMS registration is initiated on the UE. SS waits the UE to sends an uncompressed initial REGISTER request (or 
compressed in the case the 'UE compresses the initial REGISTER message') with SIP Compression 
announcement 'comp=sigcomp'. 

2) SS responds to the initial REGISTER request with a compressed valid 401 Unauthorized response, headers 
populated according to the 401 response common message definition. 

3) SS waits for the UE to set up a temporary set of security associations and send another uncompressed 
REGISTER request over those security associations (or compressed in the case: 'UE compresses the initial 
REGISTER message' or 'UE compress upon receiving the first compressed message'), with SIP Compression 
announcement 'comp=sigcomp'. 

4) SS responds to the second REGISTER request with valid compressed 200 OK response, sent over the same 
temporary set of security associations that the UE used for sending the REGISTER request. SS shall populate the 
headers of the 200 OK response according to the 200 response for REGISTER common message definition. 

5) SS waits for the UE to send an uncompressed SUBSCRIBE request (or compressed in the case 'UE compress 
upon receiving the first compressed message') with SIP Compression announcement 'comp=sigcomp'. 

6) SS responds to the SUBSCRIBE request with a valid compressed 200 OK response, headers populated according 
to the 200 response for SUBSCRIBE common message definition with the SIP Compression announcement 
'comp=sigcomp' in the record-route header. 

7) SS sends UE a compressed NOTIFY request for the subscribed registration event package. In the request the 
Request URI, headers and the request body shall be populated according to the NOTIFY common message 
definition. 

8) SS waits for the UE to respond the NOTIFY with compressed 200 OK response. 
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Expected sequence 



Step 


Direction 


lUlessage 


Comment 


UE 1 SS 


1 


^ 


REGISTER 


UE sends initial registration for IIVIS services with 
comp=sigcomp in the Via and Contact headers. The 
message is uncompressed. 


1a 






Optional The message is compressed, according to 
the capability 'UE compress the initial REGISTER 
message', using SigComp. 


2 


-^ 


401 Unauthorized 


The SS responds with an authentication challenge 
compressed message. 


3 


^ 


REGISTER 


UE completes the security negotiation procedures 
sending another REGISTER. The message is 
uncompressed. 


3a 






Optional The message is compressed, according to 
the capability 'UE compress the initial REGISTER 
message' or 'UE compress upon receiving 
compressed message', using SigComp. 


4 


<- 


200 OK 


The SS responds with 200 OK compressed 
message. 


5 


■^ 


SUBSCRIBE 


UE subscribes to its registration event package. 
The message is uncompressed with sigcomp. 


5a 






Optional The message is compressed, according to 
the capability 'UE compress the initial REGISTER 
message' or 'UE compress upon receiving 
compressed message', using SigComp. 


6 


^ 


200 OK 


The SS responds SUBSCRIBE with 200 OK 
compressed message. 


7 


^ 


NOTIFY 


The SS sends initial NOTIFY for registration event 
package. The message is compressed. 


8 


-^ 


200 OK 


The UE responds the NOTIFY with 200 OK 
compressed message 



Specific Message Contents 

REGISTER (Step 1) 

Use the default message 'REGISTER' in annex A.1.1, condition Al "Initial unprotected REGISTER", with the 
following exceptions: 



Header/param 


Value/remarl< 


Via 

via-compression 


comp=sigcomp 


Contact 

compression-param 


comp=sigcomp 
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401 Unauthorized for REGISTER (Step 2) 

Use the default message '401 Unauthorized for REGISTER' in annex A. 1.2. 

REGISTER (Step 3) 

Use the default message 'REGISTER' in annex A. 1.1, condition A2 "Subsequent REGISTER sent over security 
associations", with the following exceptions: 



Header/param 


Value/remark 


Via 

via-compression 


comp=sigcomp 


Contact 

compression-param 


comp=sigcomp 



200 OK for REGISTER (Step 4) 

Use the default message '200 OK for REGISTER' in annex A. 1.3. 

SUBSCRIBE (Step 5) 

Use the default message 'SUBSCRIBE for reg-event package' in annex A. 1.4 with the following exceptions: 



Header/param 


Value/remarl< 


Via 

via-compression 


comp=sigcomp 


Contact 

compression-param 


comp=sigcomp 



200 OK for SUBSCRIBE (Step 6) 

Use the default message '200 OK for SUBSCRIBE' in annex A. 1.5 with the following exceptions: 



Header/param 


Value/remarl< 


Record-Route 

compression-param 


comp=sigcomp 



NOTIFY (Step 7) 

Use the default message 'NOTIFY for reg-event package' in annex A. 1.6. with the following exceptions: 



Header/param 


Value/remarl< 


Via 

via-parmi : 

via-compression 


comp=sigcomp 



200 OK for NOTIFY (Step 8) 

Use the default message '200 OK for other requests than REGISTER or SUBSCRIBE' in annex A.3.1. 

13.1.5 Test requirements 

Step 1: SS shall check that in accordance to the 3GPP TS 24.229 [10] clause 8.1.1 the UE sends initial REGISTER 
request as follows: 
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a) the Via header contains the SIP Compression announcement 'comp=sigcomp'; and 

b) the Contact header contains the SIP Compression announcement 'comp=sigcomp'; and 

c) the message is sent compressed according to RFC 3320 [24] in case the 'UE compresses the initial REGISTER 
message'; and 

d) the compression support SIP dictionary specified in RFC 3485 [25]; and 

Step 3: SS shall check that in accordance to the 3GPP TS 24.229 [10] clause 8.1.1 the UE sends second REGISTER 
request as follows: 

a) the Via header contains the SIP Compression announcement 'comp=sigcomp'; and 

b) the Contact header contains the SIP Compression announcement 'comp=sigcomp'; and 

c) the message is sent compressed according to RFC 3320 [24] in case the 'UE compresses the initial REGISTER 
message' or 'UE compress upon receiving the first compressed message'; and 

Step 5: SS shall check that, in accordance to the 3GPP TS 24.229 [10] clause 8.1.1, the UE sends a SUBSCRIBE 
request as follows: 

a) the Via header contains the SIP Compression announcement 'comp=sigcomp'; and 

b) the Contact header contains the SIP Compression announcement 'comp=sigcomp'; and 

c) the message is sent compressed according to RFC 3320 [24] in case the 'UE compresses the initial REGISTER 
message' or 'UE compress upon receiving the first compressed message'; and 

Step 8: SS shall check that, in accordance to the 3GPP TS 24.229 [10] clause 8.1.1, the UE sends a 200 OK for 
NOTIFY response as follows: 

a) the Via header contains the SIP Compression announcement 'comp=sigcomp'; and 

b) the message is sent compressed according to RFC 3320 [24]. 



14 Emergency Service 

14.1 Emergency Call Initiation - Using CS domain 



14.1.1 Definition and applicability 

Test to verify that the UE correctly requests an emergency service on the CS domain. This process is described in 
3GPP TS 24.229 [10], clauses 5.1.6. 

14.1.2 Conformance requirement 

If the UE does recognise the emergency call MMI(s) (i.e. the dialled number is stored in USIM/ME), then the UE shall 
use the CS CN domain to attempt to establish the emergency call. 

A UE shall not attempt to establish an emergency session via the IM CN Subsystem when the UE can detect that the 
number dialled is an emergency number. The UE shall use the CS domain as described in 3GPP TS 24.008. 

As a consequence of this, a UE operating in MS operation mode C cannot perform emergency calls. 

Reference(s) 

3GPPTS 24.229[10], clauses 5.16; 3GPP TS 22.101[39], clause 10.4 
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14.1.3 Test purpose 

To verify that when calling an emergency number the UE attempts an emergency call setup according to the procedures 
described in 3GPP TS 24.008 [12] 

14.1.4 Method of test 

Initial conditions 

UE contains ISIM and USIM applications or only USIM application on UICC. UE has activated a PDP context, 
discovered P-CSCF and registered to IMS services, by executing the generic test procedure in Annex C.2 up to the last 
step. 

SS is configured with the shared secret key of IMS AKA algorithm, related to the IMS private user identity (IMPI) 
configured on the UICC card equipped into the UE. SS has performed AKAvl-MD5 authentication with the UE and 
accepted the registration. 

Related ICS/IXIT Statement(s 

UE supports Emergency speech call (Yes/No) 

Test procedure 

1) MO call is initiated on the UE by dialling emergency number, e.g. 112. 

2) SS waits for an emergency call setup according to the procedures described in 3GPP TS 24.008 [12]. 

3) Having reached the active state, the call is cleared by the SS. 

Expected sequence 



Step 


Direction 


Message 


Comment 


UE 1 SS 


1 






MO call is initiated on the UE by dialling emergency 
number, e.g. 112. 

The dialled number shall be one programmed in 
test USIM EFecc (Emergency Call Codes), ret. 
34.1 08 [40] clause 8.3.2.21. 


2 






SS waits for an emergency call setup according to 
the procedures described in 3GPP TS 24.008[12] 


3 






Having reached the active state, the call is cleared 
by the SS 



Specific Message Contents 
None 

14.1.5 Test requirements 

Step 2, 3: SS must check that the emergency call on the CS domain is successfully established according to the 
procedures described in 3GPP TS 24.008 [12]. 

1 4.2 Emergency Call Initiation - 380 Alternative Service 
14.2.1 Definition and applicability 

Test to verify that the UE correctly requests an emergency service on CS domain if the UE has received a 380 
(Alternative Service) response to an INVITE request. This process is described in 3GPP TS 24.229 [10], clauses 5.1.6. 
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14.2.2 Conformance requirement 



If the UE does not recognise the emergency call MMI(s) (i.e. the dialled number is not stored in USIM/ME) but the 
serving network recognises the dialled number as an emergency call number used in the country then the IM CN 
subsystem shall inform the UE to use a CS CN domain for emergency services. 

In the event the UE receives a 380 (Alternative Service) response to an INVITE request the response containing a XML 
body that includes an <alternative service> element with the <type> child element set to "emergency", the UE shall 
automatically: 

send an ACK request to the P-CSCF as per normal SIP procedures; 

attempt an emergency call setup according to the procedures described in 3GPP TS 24.008. 
The UE may also provide an indication to the user based on the text string contained in the <reason> element. 
As a consequence of this, a UE operating in MS operation mode C cannot perform emergency calls. 

Reference(s) 

3GPPTS 24.229 [10], clauses 5.16; 3GPPTS 22. 101 [39], clause 10.4 

14.2.3 Test purpose 

To verify that if the UE is not able to detect that an emergency number has been dialled: 

in the event the UE receives a 380 (Alternative Service) response to an INVITE request the response containing 
a XML body that includes an <alternative service> element with the <type> child element set to "emergency", 
the UE: 

send an ACK request to the P-CSCF as per normal SIP procedures; 

attempt an emergency call setup according to the procedures described in 3GPP TS 24.008 [12]. 

14.2.4 Method of test 

Initial conditions 

UE contains ISIM and USIM applications or only USIM application on UICC. UE has activated a PDP context, 
discovered P-CSCF and registered to IMS services, by executing the generic test procedure in Annex C.2 up to the last 
step. 

SS is configured with the shared secret key of IMS AKA algorithm, related to the IMS private user identity (IMPI) 
configured on the UICC card equipped into the UE. SS has performed AKAvl-MD5 authentication with the UE and 
accepted the registration. 

Related ICS/IXIT Statement(s) 

UE supports Emergency speech call (Yes/No) 

UE capable of initiating a bidirectional voice session over IMS (Yes/No) 

UE capable of using Tel URI for setting up a voice session (Yes/No) 

Test procedure 

1) MO call is initiated on the UE by dialling a non emergency number. 

2) SS waits the UE to send an INVITE request with Request-URI that matches the non emergency number 
dialled. 

3) SS responds to the INVITE request with a 380 Alternative Service. 
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4) SS waits for the UE to send an ACK to acknowledge receipt of the 380 Alternative Service. 

5) SS waits for an emergency call setup according to the procedures described in 3GPP TS 24.008 [12]. 

6) Having reached the active state, the call is cleared by the SS. 

Expected sequence 



Step 


Direction 


lUlessage 


Comment 


UE SS 


1 






IVIO call is initiated on the UE by dialling a 'non 
emergency' number. 

The dialled number shall not be one programmed in 
test USIIVI field EFecc (Emergency Call Codes), ret. 
34.108[40] clause 8.3.2.21. 


2 


^ 


INVITE 


UE sends INVITE. Request-URI of the INVITE 
request matches with the 'non emergency' number 
dialled. 


3 


^ 


380 Alternative Service 


The SS responds with a 380 Alternative Service 


4 


^ 


ACK 


The UE acknowledges the receipt of 200 OK for 
INVITE and starts the emergency call in CS domain 


5 






SS waits for an emergency call setup according to 
the procedures described in 3GPP TS 24.008[12] 


6 






Having reached the active state, the call is cleared 
by the SS 



Specific Message Contents 
380 Alternative Service (Step 3) 



Header/param 


Value/remarl< 


Rel 


Reference 


Status-Line 






RFC 3261 [15] 


SlP-Version 


SIP/2.0 






Status-Code 


380 






Reason-Phrase 


Alternative Service 






XML Message body 








<alternative service> 








<type> 


Emergency 







Editor"s note: This table has got a special format with 2 extra columns as this message is supposed to be moved to 
the default messages from the next meeting. 



14.2.5 Test requirements 



SS must check that the UE sends all the requests over the security associations set up during registration, in accordance 
to 3GPP TS 24.229 [10], clause 5.1. 1.5.1. Step 2: the UE shall send an INVITE message with correct content. 

Step 2: the UE sends an INVITE message with correct content. 

Step 4: the UE shall send an ACK. 

Step 5, 6: SS must check that the emergency call on the CS domain is successfully established according to the 
procedures described in 3GPP TS 24.008 [12]. 



ETSI 



3GPP TS 34.229-1 version 5.0.0 Release 5 111 ETSI TS 1 34 229-1 V5.0.0 (2006-06) 



Annex A (normative): 
Default Messages 



For all the message definitions below, the acceptable order and syntax of headers and fields within these headers must 
be according to IETF RFCs where those headers have been defined. Typically the order of headers is not significant, but 
there are well defined exceptions (like Via, Route and Record-Route headers) where the order is important. 

The contents of the messages described in the present Annex is not complete - only the fields and headers required to be 
checked or generated by SS are listed here. The messages sent by the UE may contain additional parameters, fields and 
headers which are not checked and must thus be ignored by SS. 

Values prefixed with px_ will be implemented in the TTCN with a PIXIT. 

Values shown in italics shall be used in the messages as such. 
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A.1 Default messages for IMS Registration 



A.1.1 REGISTER 



hHeader/param 


Cond 


Value/remark 


Re! 


Reference 


Request-Line 

Method 
Request-URI 

SIP-Version 


A1, A2 


REGISTER 

px_HomeDomainName (when using ISIM) or 

home domain name derived from px IMSI (when using 

USIM) 

SIP/2.0 




RFC 3261 [15] 


Route 

route-param 
route-param 


A1, A2 

A1 

A2 


(if present) 

<s/p.px_pcscf;/r> 

<s/p.px_pcscf:protected server port of P-CSCF ;lr> 




RFC 3261 [15] 


Via 

sent-protocol 

sent-by 

sent-by 
via-branch 


A1, A2 

A1 

A2 
A1, A2 


SIP/2.0/UDP {when using UDP) or 

SIP/2.0/TCP (when using TCP) 

indicate an unprotected port from which the request was 

sent. Port number may be omitted if the request was sent 

from port 5060. 

IP address or FQDN and protected server port of the UE 

value starting with "z9hG4bk" 




RFC 3261 [15] 


From 

addr-spec 

tag 


A1, A2 


px_PublicUserldentity (when using ISIM) or 

public user identity derived from px IMSI (when using 

USIM) 

must be present, value not checked 




RFC 3261 [15] 


To 

addr-spec 

tag 


A1, A2 


px_PublicUserldentity (when using ISIM) or 

public user identity derived from px IMSI (when using 

USIM) 

must not be present 




RFC 3261 [15] 


Contact 

addr-spec 

addr-spec 
expires 


A1, A2 
A1 

A2 

A1,A2 


SIP URI to either indicate an unprotected port selected by 

the UE or no port at all 

SIP URI with IP address or FQDN and protected server 

port of UE 

600000 (if present, see Rule 1) 




RFC 3261 [15] 


Expires 

delta-seconds 


A1, A2 


(if present, see Rule 1) 

600000 




RFC 3261 [15] 


Require 

option-tag 


A1, A2 


sec-agree 




RFC 3261 [15] 
RFC 3329 [21] 


Proxy-Require 

option-tag 


A1, A2 


sec-agree 




RFC 3261 [15] 
RFC 3329 [21] 


Supported 

option-tag 


A1, A2 


path 




RFC 3261 [15] 


CSeq 

value 
value 
method 


A1,A2 

A1 

A2 


must be present, value not checked 

must be incremented from the previous REGISTER 

REGISTER 




RFC 3261 [15] 


Call-ID 

Call-ID 
Call-ID 


A1, A2 

A1 

A2 


value not checked 

the same value as in the previous REGISTER 




RFC 3261 [15] 


Security-Client 

mechanism- 
name 


A1, A2 


ipsec-Sgpp 




RFC 3329 [21] 
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hHeader/param 


Cond 


Value/remarl< 


Rel 


Reference 


algorithm 

protocol 

mode 

spi-c 

spi-s 

port-c 
port-s 

mechanism- 
name 

algorithm 

protocol 
mode 
spi-c 
spi-s 

port-c 
port-s 




hmac-md5-96 

esp (if present) 

trans (if present) 

SPI number of the inbound SA at the protected client port 

SPI number of the inbound SA at the protected server 

port 

protected client port 

protected server port 

ipsec-Sgpp 

hmac-sha-1-96 

esp (if present) 

trans (if present) 

SPI number of the inbound SA at the protected client port 

SPI number of the inbound SA at the protected server 

port 

protected client port 

protected server port 






Security-Verify 

sec-mechanism 


A2 
A2 


(not present when A1) 

same value as SecurityServer header sent by SS 




RFC 3329 [21] 


Authorization 

username 

realm 

nonce 
digest-uri 
response 
algorithm 


A1 
A1 

A1 

A1 
A1 
A1 
A1 


px_PrivateUserldentity (when using ISIM) or 

private user identity derived from px IMSI (when using 

USIM) 

px_HomeDomainName (when using ISIM) or 

home domain name derived from px IIVISI (when using 

USIM) 

set to an empty value 

SIP URI formed from pxHomeDomainName 

set to an empty value 

AKAV1-MD5 




RFC 2617 [16] 
RFC 3310 [17] 


Authorization 

username 

realm 

nonce 

opaque 

digest-uri 

qop-value 

cnonce-value 

nonce-count 

response 
algorithm 


A2 
A2 

A2 

A2 
A2 
A2 
A2 
A2 
A2 

A2 
A2 


px_PrivateUserldentity (when using ISIM) or 

private user identity derived from px IMSI (when using 

USIM) 

px_HomeDomainName (when using ISIM) or 

home domain name derived from px IMSI (when using 

USIM) 

same value as in WWW-Authenticate header sent by SS 

px_Opaque 

SIP URI formed from px_HomeDomainName 

auth 

value assigned by UE affecting the response calculation 

counter to indicate how many times UE has sent the 
same value of nonce within successive REGISTERS, 
initial value shall be 1 
response calculated by UE 
AKAV1-MD5 




RFC 2617 [16] 
RFC 3310 [17] 


Max-Forwards 

value 


A1, A2 


non-zero value 




RFC 3261 [15] 


P-Access- 
Network-lnfo 

access-net- 
spec 


A2 
A2 


(not present when A1) 

access network technology and, if applicable, the cell ID 




RFC 3455 [18] 


Content-Length 

value 


A1, A2 


length of request body, if such is present 




RFC 3261 [15] 
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Rule 1: The REGISTER request must contain either an Expires header or an expires parameter in the Contact 
header. If both are present the value of Expires header is not important. 



Condition 


Explanation 


A1 
A2 


Initial unprotected REGISTER 

Subsequent REGISTER sent over security associations 



A.1 .2 401 Unauthorized for REGISTER 



Header/param 


Value/remark 


Rel 


Reference 


Status-Line 

SIP-Version 
Status-Code 
Reason-Phrase 


SIP/2.0 

401 

Unauthorized 




RFC 3261 [15] 


Via 

via-parm 


same value as received in REGISTER message 




RFC 3261 [15] 


To 

addr-spec 
tag 


same value as received in REGISTER message 
pxToTagRegister 




RFC 3261 [15] 


From 

addr-spec 
tag 


same value as received in REGISTER message 
same value as received in REGISTER message 




RFC 3261 [15] 


Call-ID 

value 


same value as received in REGISTER message 




RFC 3261 [15] 


CSeq 

value 


same value as received in REGISTER message 




RFC 3261 [15] 


www-Authenticate 

realm 

algorithm 
qop-value 
nonce 
opaque 


px HomeDomainName or home domain name derived from 

px IMS! 

AKAV1-MD5 

auth 

Base 64 encoding of RAND and AUTN 

pxOpaque 




RFC 2617 [16] 
RFC 3310 [17] 


Security-Server 

mechanism-name 

algorithm 

spi-c 

spi-s 

port-c 

port-s 


ipsec-Sgpp 

pxJpSecAlgorithm 

SPI number of the inbound SA at the protected client port 

SPI number of the inbound SA at the protected server port 

px_SSProtectedClientPort 

px_SSProtectedServerPort 




RFC 3329 [21] 


Content-Length 

value 







RFC 3261 [15] 
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A.1.3 200 OK for REGISTER 



Header/param 


Value/remark 


Rel 


Reference 


Status-Line 

SIP-Version 
Status-Code 
Reason-Phrase 


SIP/2.0 

200 

OK 




RFC 3261 [15] 


Via 

via-parm 


same value as received in REGISTER message 




RFC 3261 [15] 


To 

addr-spec 
tag 


same value as received in REGISTER message 
pxToTagRegister 




RFC 3261 [15] 


From 

addr-spec 
tag 


same value as received in REGISTER message 
same value as received in REGISTER message 




RFC 3261 [15] 


Call-ID 

value 


same value as received in REGISTER message 




RFC 3261 [15] 


CSeq 

value 


same value as received in REGISTER message 




RFC 3261 [15] 


Contact 

addr-spec 
expires 


same value as received in REGISTER message 
px_RegisterExpiration 




RFC 3261 [15] 


P-Associated-URI 

addr-spec 
addr-spec 


order of the parameters in this header must be like in this table 

px_PublicUserldentity 

px_AssociatedTelUri any arbitary TEL URI for the user 




RFC 3455 [18] 


Service-Route 

addr-spec 
uri-parameter 


pxscscf 
Ir 




RFC 3608 [19] 


Path 

addr-spec 
uri-parameter 


pxpcscf 

Ir 




RFC 3327 [20] 


Content-Length 

value 







RFC 3261 [15] 
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A.1 .4 SUBSCRIBE for reg-event package 



hHeader/param 


Value/remark 


Re! 


Reference 


Request-Line 

Method 

Request-URI 

SIP-Version 


SUBSCRIBE 

px_PublicUserldentity 

SIP/2.0 




RFC 3261 [15] 


Route 

route-param 


order of the parameters in this header must be like in this table 

<s/p.px_pcscf:protected server port of P-CSCF;fr>, 
<s/p.px scscf;fr> 




RFC 3261 [15] 


Via 

sent-protocol 

sent-by 
via-branch 


SIP/2.0/UDP when using UDP or 

SIP/2.0/TCP when using TCP 

IP address or FQDN and protected server port of the UE 

value starting with "z9hG4bk" 




RFC 3261 [15] 


From 

addr-spec 
tag 


px_PublicUserldentity 

must be present, value not checked but stored for later reference 




RFC 3261 [15] 


To 

addr-spec 
tag 


px_PublicUserldentity 
must not be present 




RFC 3261 [15] 


Contact 

addr-spec 


SIP URI with IP address or FQDN and protected server port of UE 




RFC 3261 [15] 


Expires 

delta-seconds 


600000 




RFC 3261 [15] 


Security-Verify 

sec-mechanism 


same value as SecurityServer header sent by SS 




RFC 3329 [21] 


Require 

option-tag 


sec-agree 




RFC 3261 [15] 
RFC 3329 [21] 


Proxy-Require 

option-tag 


sec-agree 




RFC 3261 [15] 
RFC 3329 [21] 


CSeq 

value 
method 


must be present, value not checked 
SUBSCRIBE 




RFC 3261 [15] 


Call-ID 

callid 


value not checked, but stored for later reference 




RFC 3261 [15] 


Max-Forwards 

value 


non-zero value 




RFC 3261 [15] 


P-Access-Network- 
Info 

access-net-spec 


access network technology and, if applicable, the cell ID 




RFC 3455 [1 8] 


Accept 

media-range 


(if present) 

application/reginfo+xml 




RFC 3261 [15] 
RFC 3680 [22] 


Event 

event- type 


reg 




RFC 3265 [34] 
RFC 3680 [22] 


Content-Length 

value 


length of request body, if such is present 




RFC 3261 [15] 
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A.1 .5 200 OK for SUBSCRIBE 



l-leader/param 


Value/remark 


Rel 


Reference 


Status-Line 

SIP-Version 
Status-Code 
Reason-Phrase 


SIP/2.0 

200 

OK 




RFC 3261 [15] 


Via 

via-parm 


same value as received in SUBSCRIBE message 




RFC 3261 [15] 


To 

addr-spec 
tag 


px_PublicUserldentity 
px_ToTagSubscribeDialog 




RFC 3261 [15] 


From 

addr-spec 
tag 


same value as received in SUBSCRIBE message 
same value as received in SUBSCRIBE message 




RFC 3261 [15] 


Call-ID 

value 


same value as received in SUBSCRIBE message 




RFC 3261 [15] 


CSeq 

value 


same value as received in SUBSCRIBE message 




RFC 3261 [15] 


Contact 

addr-spec 


<s/p.px_scscf> 




RFC 3261 [15] 


Expires 

delta-seconds 


600000 




RFC 3261 [15] 


Record-Route 

addr-spec 
uri-parameter 


pxpcscf: protected server port of P-CSCF 
Ir 




RFC 3261 [15] 


Content-Length 

value 







RFC 3261 [15] 
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A.1 .6 NOTIFY for reg-event package 



Header/param 


Value/remark 


Re! 


Reference 


Request-Line 

Method 

Request-URI 

SIP-Version 


NOTIFY 

SIP URI with IP address or FQDN and protected server port of UE 

SIP/2.0 




RFC 3261 [15] 


Via 

via-parmi : 

sent-protocol 

sent-by 
via-branch 
via-parm2: 
sent-protocol 

sent-by 
via-branch 


order of the parameters in this header must be like in this table 

SIP/2.0/UDP when using UDP or 
SIP/2.0/TCP when using TCP 
IP address and protected server port of SS 
value starting with "z9hG4bk" 

SIP/2.0/UDP when using UDP or 

SIP/2.0/TCP when using TCP 

pxscscf 

value starting with "z9hG4bk" 




RFC 3261 [15] 


From 

addr-spec 
tag 


px_PublicUserldentity 
px_ToTagSubscribeDialog 




RFC 3261 [15] 


To 

addr-spec 
tag 


px_PublicUserldentity 

same value as received in From tag of SUBSCRIBE message 




RFC 3261 [15] 


Call-ID 

callid 


same as value received in SUBSCRIBE message 




RFC 3261 [15] 


CSeq 

value 
method 


1 
NOTIFY 




RFC 3261 [15] 


Contact 

addr-spec 


<s/p.px_scscf> 




RFC 3261 [15] 


Content-Type 

media-type 


application/reginfo+xml 




RFC 3261 [15] 
RFC 3680 [22] 


Event 

event-type 


reg 




RFC 3265[34] 
RFC 3680 [22] 


Max-Forwards 

value 


69 




RFC 3261 [15] 


Subscription-State 

substate-value 
expires 


active 
600000 




RFC 3265[34] 


Content-Length 

value 
Message-body 


length of message-body 

<?xml version='1.0?> 

<reginfo xmlns='um:ietf:params:xml:ns:reginfo' version='0' 
state='fuir> 
<registration ao/'='px_PublicUserldentity' id='a100' state='active'> 
<contact id='980' state=' active' event='registered'> 
<ur/>same value as in Contact header of REGISTER 
request</ur/> 
</contact> 
</registration> 

<registration ao/'='px_AssociatedTelUri' id='a101' state='active'> 
<contact id='981' state='active' event='created'> 
<uri>same value as in Contact header of REGISTER 
request</ur/> 
</contact> 
</registration> 
</reginfo> 




RFC 3261 [15] 




RFC 3680 [22] 



£75/ 



3GPP TS 34.229-1 version 5.0.0 Release 5 



119 



ETSI TS 134 229-1 V5.0.0 (2006-06) 



A.1 .7 423 Interval Too Brief for REGISTER 



Header/param Value/remark 
Status-Line 

SIP-Version SIP/2.0 

Status-Code 423 

Reason-Phrase Interval Too Brief 



Via 



via-parm 



same value as received in REGISTER message 



To 



addr-spec same value as received in REGISTER message 
tag pxToTagRegister 



IVIin-Expires 

delta-seconds 



T (a decimal integer number of seconds from to 
(2**32)-1) 



Re! 



From 




addr-spec 


same value as received in REGISTER message 


Call-ID 




value 


same value as received in REGISTER message 


CSeq 




value 


same value as received in REGISTER message 



Reference 

RFC 3261 [15] 



RFC 3261 [15] 
RFC 3261 [15] 

RFC 3261 [15] 
RFC 3261 [15] 
RFC 3261 [15] 
RFC 3261 [15] 
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A.2 Default messages for Call Setup 
A.2.1 INVITE for MO Call Setup 



Header/param 


Value/remark 


Rel 


Reference 


Request-Line 

Method 

Request-URI 

SIP-Version 


INVITE 

px_CalleeUri 

SIP/2.0 




RFC 3261 [15] 


Via 

sent-protocol 

sent-by 
via-branch 


SIP/2.0/UDP (when using UDP) or 

SIP/2.0/TCP (when using TCP) 

IP address or FQDN and protected server port of the UE 

value starting with "z9hG4bk" 




RFC 3261 [15] 


Route 

route-param 


order of the parameters in this header must be like in this table 
<s/p.px_pcscf:px_SSProtectedServerPort;//->, <s/p.px_scscf;/r> 




RFC 3261 [15] 


From 

addr-spec 
tag 


any SIP URI except public user identity derived from pxJMSI 
must be present, value not checked 




RFC 3261 [15] 


To 

addr-spec 
tag 


px_CalleeUri 
not present 




RFC 3261 [15] 


Call-ID 

callid 


value different to that received in REGISTER message 




RFC 3261 [15] 


CSeq 

value 
method 


must be present, value not checked 
INVITE 




RFC 3261 [15] 


Supported 

option-tag 


WOrel 




RFC 3261 [15] 


Require 

option-tag 


precondition, sec-agree 




RFC 3261 [15] 
RFC 3312 [31] 
RFC 3329 [21] 


Proxy-Require 

option-tag 


sec-agree 




RFC 3261 [15] 
RFC 3329 [21] 


Security-Verify 

sec-mechanism 


same value as SecurityServer header sent by SS 




RFC 3329 [21] 


Contact 

addr-spec 


SIP URI with IP address or FQDN and protected server port of UE 




RFC 3261 [15] 


Content-Type 

media-type 


appiication/sdp 




RFC 3261 [15] 


Max-Forwards 

value 


non-zero value 




RFC 3261 [15] 


P-Access-Network- 
Info 

access-net-spec 


access network technology and, if applicable, the cell ID 




RFC 3455 [18] 


Content-Length 

value 


length of message-body 




RFC 3261 [15] 
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A.2.2 100 Trying for INVITE 



hHeader/param 


Value/remark 


Rel 


Reference 


Status-Line 

SIP-Version 
Status-Code 
Reason-Phrase 


SIP/2.0 

100 

Trying 




RFC 3261 [15] 


Via 

via-parm 


same value as received in INVITE message 




RFC 3261 [15] 


From 

addr-spec 
tag 


same value as received in INVITE message 
same value as received in INVITE message 




RFC 3261 [15] 


To 

addr-spec 
tag 


same value as received in INVITE message 
not present 




RFC 3261 [15] 


Call-ID 

callid 


same value as received in INVITE message 




RFC 3261 [15] 


CSeq 

value 


same value as received in INVITE message 




RFC 3261 [15] 


Content-Length 

value 







RFC 3261 [15] 
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A.2.3 183 Session in Progress for INVITE 



hHeader/param 


Cond 


Value/remark 


Rel 


Reference 


Status-Line 

SIP-Version 
Status-Code 
Reason-Plirase 


A3,A4 


SIP/2.0 

183 

Session in Progress 




RFC 3261 [15] 


Record-Route 

rec-route 


A3,A4 


order of the parameters in this header must be like in this 

table 

<sip:pcscf. other. com;ir>, <sip:scscf. other. com;ir>, 

<sip:orig@px_scsd;ir>, 

<s/p.px pcscf:px SSProtectedServerPort;fr> 




RFC 3261 [15] 


Via 

via-parm 


A3,A4 


same value as received in INVITE message 




RFC 3261 [15] 


Require 

option-tag 


A3,A4 


WOrei 




RFC 3261 [15] 


From 

addr-spec 
tag 


A3,A4 


same value as received in INVITE message 
same value as received in INVITE message 




RFC 3261 [15] 


To 

addr-spec 
tag 


A3,A4 


same value as received in INVITE message 
px_lnviteToTag 




RFC 3261 [15] 


Contact 

addr-spec 
addr-spec 


A3,A4 

A3 

A4 


px_CalleeContactUri 

SIP URI with IP address or FQDN and protected server 
port of UE 




RFC 3261 [15] 


Rseq 

response-num 


A3,A4 


px_RSeqNumFor183 




RFC 3262 [33] 


Call-ID 

callid 


A3,A4 


same value as received in INVITE message 




RFC 3261 [15] 


CSeq 

value 


A3,A4 


same value as received in INVI 1 b message 




RFC 3261 [15] 


Allow 

method 


A3,A4 


UPDATE 




RFC 3261 [15] 


Content-Type 

media-type 


A3,A4 


application/sdp 




RFC 3261 [15] 


Content-Length 

value 


A3,A4 


length of message-body 




RFC 3261 [15] 
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Header/param 


Cond 


Value/remark 


Rel 


Reference 


Message-body 


A3,A4 


SDP body of the 183 response copied from the received 
INVITE but modified as follows: 

- IP address on "o=" and "c=" lines and transport port on 
"m=" lines changed to indicate to which IP address and 
port the UE should start sending the media; and 

- optional "a=sendonly" line inverted to "a=recvonly" and 
vice versa 

- the "a=" lines describing the current and desired state of 
the preconditions, updated as follows: 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local [direction-tag] (* 

a=des:qos mandatory remote [direction-tag] (* 

a=conf:qos remote [direction-tag] {** 

*) The value of direction-tags in 183 must be the inverse 
from those of INVITE (both a= lines for local and remote). 
If the INVITE contained the direction-tag as "recv" the 
183 must have it as "send" and vice versa. The value 
"sendrecv" will be kept as is. The value for direction tag of 
remote must be the same as for local.. 

**) The value of direction-tag for conf:qos remote shall be 
the same as for des: qos mandatory remote. 




RFC 2327 [27] 
RFC 3264 [30] 
RFC 3312 [31] 



Condition 


Explanation 


A3 
A4 


MO call setup 
IVIT call setup 
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A.2.4 PRACK 



l-leader/param 


Value/remark 


Re! 


Reference 


Request-Line 

Method 

Request-URI 

SIP-Version 


PRACK 

same value as in Contact header of 183 response 

SIP/2.0 




RFC 3261 [15] 


Via 

sent-protocol 

sent-by 
via-branch 


SIP/2.0/UDP (when using UDP) or 
SIP/2.0/TCP (when using TCP) 
same value as in INVITE message 
value starting with "z9hG4bk" 




RFC 3261 [15] 


Route 

route-param 


URIs of the Record-Route header of 183 response in reverse 
order 




RFC 3261 [15] 


From 

addr-spec 
tag 


same value as received in INVITE message 
same value as received in INVITE message 




RFC 3261 [15] 


To 

addr-spec 
tag 


same value as received in INVITE message 

same value as in the corresponding reliable response 




RFC 3261 [15] 


Call-ID 

callid 


same value as received in INVITE message 




RFC 3261 [15] 


CSeq 

value 
method 


value as in reliable response incremented by one 
PRACK 




RFC 3261 [15] 


Require 

option-tag 


precondition 




RFC 3261 [15] 
RFC 3329 [21] 


Max-Forwards 

value 


non-zero value 




RFC 3261 [15] 


RAck 

response-num 

cseq-num 

method 


same value as in RSeq header of the reliable response 
same value as in CSeq of reliable response 
same value as in CSeq of reliable response 




RFC 3262 [33] 


P-Access-Network- 
Info 

access-net-spec 


access network technology and, if applicable, the cell ID 




RFC 3455 [1 8] 


Content-Type 

media-type 


header shall be present only if there is SDP in message-body 
application/sdp 




RFC 3261 [15] 


Content-Length 

value 


length of message-body 




RFC 3261 [15] 


Message-body 


Optional SDP body. If included then the contents of the SDP shall 
be checked as described in the Test requirements section of the 
test case. 




RFC 2327 [27] 
RFC 3264(30] 
RFC 3312 [31] 
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A.2.5 UPDATE 



l-leader/param 


Value/remark 


Re! 


Reference 


Request-Line 

Method 

Request-URI 

SIP-Version 


UPDATE 

same value as in PRACK message 

SIP/2.0 




RFC 3261 [15] 


Via 

sent-protocol 

sent-by 
via-branch 


SIP/2.0/UDP (when using UDP) or 
SIP/2.0/TCP (when using TCP) 
same value as in INVITE message 
value starting with "z9hG4bk" 




RFC 3261 [15] 


Route 

route-param 


URIs of the Record-Route header of 183 response in reverse 
order 




RFC 3261 [15] 


From 

addr-spec 
tag 


same value as received in INVITE message 
same value as received in INVITE message 




RFC 3261 [15] 


To 

addr-spec 
tag 


same value as received in INVITE message 
same value as in 183 message 




RFC 3261 [15] 


Call-ID 

callid 


same value as received in INVITE message 




RFC 3261 [15] 


CSeq 

value 
method 


value of received in INVITE incremented by two 
UPDATE 




RFC 3261 [15] 


Require 

option-tag 


precondition, sec-agree 




RFC 3261 [15] 
RFC 3329 [21] 


Proxy-Require 

option-tag 


sec-agree 




RFC 3261 [15] 
RFC 3329 [21] 


Max-Forwards 

value 


non-zero value 




RFC 3261 [15] 


Security-Verify 

sec-mechanism 


same value as SecurityServer header sent by SS 




RFC 3329 [21] 


P-Access-Network- 
Info 

access-net-spec 


access network technology and, if applicable, the cell ID 




RFC 3455 [18] 


Content-Type 

media-type 


application/sdp 




RFC 3261 [15] 


Content-Length 

value 


length of message-body 




RFC 3261 [15] 


Message-body 


Contents of the SDP body shall be checked as described in the 
Test requirements section of the test case. 




RFC 2327 [27] 
RFC 3264(30] 
RFC 3312 [31] 
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A.2.6 180 Ringing for INVITE 



hHeader/param 


Value/remark 


Re! 


Reference 


Status-Line 

SIP-Version 
Status-Code 
Reason-Phrase 


SIP/2.0 

180 

Ringing 




RFC 3261 [15] 


Record-Route 

rec-route 


same value as in the 183 response 




RFC 3261 [15] 


Via 

via-parm 


same value as in the 183 response 




RFC 3261 [15] 


Require 

option-tag 


WOrel 




RFC 3261 [15] 


From 

addr-spec 
tag 


same value as in the 183 response 
same value as in the 183 response 




RFC 3261 [15] 


To 

addr-spec 
tag 


same value as in the 183 response 
same value as in the 183 response 




RFC 3261 [15] 


Contact 

addr-spec 


same value as in the 183 response 




RFC 3261 [15] 


Rseq 

response-num 


px_RSeqNumFor183 incremented by one 




RFC 3262 [33] 


Call-ID 

callid 


same value as in the 183 response 




RFC 3261 [15] 


CSeq 

value 


same value as in the 183 response 




RFC 3261 [15] 


Content-Length 

value 







RFC 3261 [15] 
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A.2.7 ACK 



hHeader/param 


Value/remark 


Re! 


Reference 


Request-Line 

Method 

Request-URI 

SIP-Version 


ACK 

same value as in PRACK message 

SIP/2.0 




RFC 3261 [15] 


Via 

via-parm 


same value as received in INVITE message 




RFC 3261 [15] 


Route 

route-param 


URIs of the Record-Route header of 183 response in reverse 
order 




RFC 3261 [15] 


From 

addr-spec 
tag 


same value as received in INVITE message 
same value as received in INVITE message 




RFC 3261 [15] 


To 

addr-spec 
tag 


same value as received in INVITE message 
same value as received in 183 message 




RFC 3261 [15] 


Call-ID 

callid 


same value as received in INVITE message 




RFC 3261 [15] 


CSeq 

value 
method 


same value as received in INVITE message 
ACK 




RFC 3261 [15] 


Max-Forwards 

value 
P-Access-Network- 
Info 


non-zero value 
must not be present 




RFC 3261 [15] 




RFC 3455 [18] 


Content-Length 

value 







RFC 3261 [15] 
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A.2.8 BYE 



l-leader/param 


Value/remark 


Re! 


Reference 


Request-Line 

Method 

Request-URI 

SIP-Version 


BYE 

same value as in PRACK message 

SIP/2.0 




RFC 3261 [15] 


Via 

sent-protocol 

sent-by 
via-branch 


SIP/2.0/UDP (when using UDP) or 
SIP/2.0/TCP (when using TCP) 
same value as in INVITE message 
value starting with "z9hG4bk" 




RFC 3261 [15] 


Route 

route-param 


URIs of the Record-Route header of 183 response in reverse 
order 




RFC 3261 [15] 


From 

addr-spec 
tag 


same value as received in INVITE message 
same value as received in INVITE message 




RFC 3261 [15] 


To 

addr-spec 
tag 


same value as received in INVITE message 
same value as in the 183 message 




RFC 3261 [15] 


Call-ID 

callid 


same value as received in INVITE message 




RFC 3261 [15] 


CSeq 

value 
method 


must be present, not checked 
BYE 




RFC 3261 [15] 


Require 

option-tag 


sec-agree 




RFC 3261 [15] 
RFC 3329 [21] 


Proxy-Require 

option-tag 


sec-agree 




RFC 3261 [15] 
RFC 3329 [21] 


Max-Forwards 

value 


non-zero value 




RFC 3261 [15] 


Security-Verify 

sec-mechanism 


same value as SecurityServer header sent by SS 




RFC 3329 [21] 


P-Access-Network- 
Info 

access-net-spec 


access network technology and, if applicable, the cell ID 




RFC 3455 [18] 


Content-Length 

value 


length of message body 




RFC 3261 [15] 



£75/ 



3GPP TS 34.229-1 version 5.0.0 Release 5 



129 



ETSI TS 134 229-1 V5.0.0 (2006-06) 



A.2.9 INVITE for MT Call 



Header/param 
Request-Line 

Method 

Request-URI 

SIP-Version 



Via 



Via 



via-parm 



Record-Route 

rec-route 

Record-Route 

rec-route 

From 

addr-spec 
Tag 



To 



addr-spec 
Tag 



Call-ID 

callid 



CSeq 

value 
method 



Supported 

option-tag 



Require 

option-tag 



P-Called-Party-ID 
Contact 

addr-spec 

Content-Type 

media-type 



Max-Forwards 

value 



Content-Length 

value 



Value/remark 

INVITE 

UE"s registered contact address in SIP URI form 

SIP/2.0 



sent-protocol SIP/2.0/UDP (when using UDP) or 

SIP/2.0/TCP (when using TCP) 
sent-by IP address or FQDN and protected server port of the SS 
Via-branch value starting with "z9hG4bk" 



SIP/2. 0/UDP scscf1.3gpp.org;branch=z9hG4bK1 234567890, 
SIP/2.0/UDP scscf2.3gpp.org;branch=z9hG4bK2345678901 , 
SIP/2. 0/UDP pcscf2.3gpp. org;branch=z9hG4bk34567890 12 



SIP URI with FQDN or IP address and protected server port of the 
SS 



<sip:term@scscf1 . 3gpp. org;lr>, <sip:orig@scscf2. 3gpp. org;lr>, 
<sip:pcscf2. 3gpp. org;lr> 



an SIP URI representing the calling UE 
must be present, value not checked 



SIP or TEL URI of the UE 
not present 



a random text string generated by the SS 



must be present, value not checked 
INVITE 



WOrel 



Precondition 



One of the UE"s registered, non-barred public ID 



SIP URI with IP address or FQDN and protected server port of the 
calling UE 



appiication/sdp 



non-zero value 



Rel Reference 

RFC 3261 [15] 



RFC 3261 [15] 



RFC 3261 [15] 

RFC 3261 [15] 
RFC 3261 [15] 
RFC 3261 [15] 

RFC 3261 [15] 

RFC 3261 [15] 
RFC 3261 [15] 

RFC 3261 [15] 

RFC 3261 [15] 

RFC3455[18] 
RFC 3261 [15] 

RFC 3261 [15] 
RFC 3261 [15] 
RFC 3261 [15] 



length of message-body 
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A.3 Generic Common Messages 

A.3.1 200 OK for other requests than REGISTER or SUBSCRIBE 



l-leader/param 


Value/remark 


Rel 


Reference 


Status-Line 

SIP-Version 
Status-Code 
Reason-Phrase 


SIP/2.0 

200 

OK 




RFC 3261 [15] 


Via 

via-parm 


same value as received in request 




RFC 3261 [15] 


From 

addr-spec 
tag 


same value as received in request 
same value as received in request 




RFC 3261 [15] 


To 

addr-spec 
tag 


same value as received in request 

same value as received in request or 

px InviteToTag added if missing from request 




RFC 3261 [15] 


Call-ID 

callid 


same value as received in request 




RFC 3261 [15] 


CSeq 

value 


same value as received in request 




RFC 3261 [15] 


Content-Length 

value 







RFC 3261 [15] 
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Annex B (normative): 
Default DHCP messages 



For all the message definitions below, the acceptable order and syntax of headers and fields within these headers must 
be according to IETF RFCs where those headers have been defined. Typically the order of headers is not significant, but 
there are well defined exceptions where the order is important. 

For IPv6 DHCP messages refer to RFC 3315[23] 

For IPv4 DHCP messages refer to RFC 2131[55]. 

The contents of the messages described in the present Annex is not complete - only the fields and headers required to be 
checked or generated by SS are listed here. The messages sent by the UE may contain additional parameters, fields and 
headers which are not checked and must thus be ignored by SS. 



B.1 Default DHCP messages (IPv6) 



B.1 .1 DHCP INFORMATION-REQUEST 



msg-type 
transaction-id 



Options 



Value/Remarks 

INFORMATION-REQUEST (11) 

Check If Present 

Note the Value to be included in Reply Message 



option-code 
- option-len 
-DUID 



0PTI0N_CLIENTID(1) 
Length of the DUID of Client 
Set to DUIDof Cleint 



*Note: Numerical value, "(n)", provided in brackets in Column Value/Remarks is the 'octal' value for this option. 

B.1. 2 DHCP REPLY 



msg-type 



Options 



Value/Remarks 



REPLY (7) 



transaction-id 


Set the same value as received in the corresponding 
Uplink Information Request message 


option-code 


0PTI0N_CLIENTID(1) 


- option-len 


Length of the DUID of client 


-DUID 


Set to DUID of Cleint 


option-code 


0PTI0N_SERVERID21) 


- option-len 


Length of the DUID of Server 


-DUID 


Set to DUID of Server 



*Note: Numerical value, "(n)", provided in brackets in Column Value/Remarks is the 'octal' value for this option. 
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B.1.3 DHCP SOLICIT 



Options 



msg-type 
transaction-id 



Value/Remarks 

SOLICIT (1) 

Check If Present 

Note the Value to be included in Reply IVIessage 



option-code 
- option-len 
-DUID 


0PTI0N_CLIENTID(1) 
Length of the DUID of Client 
Set to DUID of Client 


option-code 

- option-len 

- requested-option-code 


OPTION_ORO (6) 

Check Specific message contents in test case 

Check Specific message contents in test case 



*Note: Numerical value, "(n)", provided in brackets in Column Value/Remarks is the 'octal' value for this option. 

B.1.4 DHCPADEVERTISE 



msg-type 



Options 



Value/Remarks 



ADVERTISE (2) 



transaction-id 


Set the same value as received in the corresponding 




Uplink solicit message 


option-code 


0PTI0N_CLIENTID{1) 


- option-len 


Length of the DUID of client 


-DUID 


Set to DUID of Client 


option-code 


0PTI0N_SERVERID(21) 


- option-len 


Length of the DUID of Server 


-DUID 


Set to DUID of Server 



*Note: Numerical value, "(n)", provided in brackets in Column Value/Remarks is the 'octal' value for this option. 
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B.2 Default DHCP messages (IPv4) 



B.2.1 DHCP DISCOVER 



Fields 


Value/Remarks 


op 


1 (BOOTREQUEST) 


htype 


Check if valid value is included 


hien 


Check if valid value is included 


hops 





xid 


Check For Presence 

Note the Value to be included in Offer Message 


sees 


Any Value 


flags 


Check For Presence 

Note the Value to be included in Offer Message 


ciaddr 





yiaddr 





siaddr 





giaddr 





chaddr 


FFS 


sname 


Options if indicated in sname/file else not used 


file 


Options if indicated in sname/file else not used 


options 

- code 

- len 
-Type 


* 

53 (DHCP Message Type) 

1 

1 (DHCP DISCOVER) 



■ Note: Additional options may be present 



B.2.2 DHCP OFFER 



Fields 


Value/Remarks 


op 


2 (BOOTREPLY) 


htype 


Set to SS Hardware Type 


hIen 


Set to SS Hardware Address Len 


hops 





xid 


Set to same value as received in corresponding 
DISCOVER message 


sees 





flags 


Set to same value as received in corresponding 
DISCOVER message 


ciaddr 





yiaddr 


IP address of Mobile 


siaddr 


Set to IP address of next Boot Strap server 


giaddr 


Set to same value as received in corresponding 
DISCOVER message 


chaddr 


Set to same value as received in corresponding 
DISCOVER message 


sname 


Set to Server Host name 


file 


Set to Client Boot File Name 


options 


* 


-code 
- len 
-Type 


53 (DHCP Message Type) 

1 

2 (DHCP OFFER) 



■ Note: Additional options included in response to options requested by UE and supported by SS 
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B.2.3 DHCP INFORM 



Fields 


Value/Remarks 


op 


1 (BOOTREQUEST) 


htype 


Check if valid value is included 


hien 


Check if valid value is included 


hops 





xid 


Check For Presence 

Note the Value to be included in Offer IVIessage 


sees 


Any Value 


flags 


Check For Presence 

Note the Value to be included in Offer Message 


ciaddr 


Set to UE"s Network address 


yiaddr 





siaddr 





giaddr 





chaddr 


FFS 


sname 


Options if indicated in sname/file else not used 


file 


Options if indicated in sname/file else not used 


options 


* 


- code 

- len 
-Type 


53 (DHCP IVIessage Type) 

1 

8 (DHCP INFORM) 



■ Note: Additional options may be present 



B.2.4 DHCPACK 



Fields 


Value/Remarks 


op 


2 (BOOTREPLY) 


htype 


Set to SS Hardware Type 


hIen 


Set to SS Hardware Address Len 


hops 





xid 


Set to same value as received in corresponding 
INFORM message 


sees 





flags 


Set to same value as received in corresponding 
INFORM message 


ciaddr 





yiaddr 


IP address of Mobile 


siaddr 


Set to IP address of next Boot Strap server 


giaddr 


Set to same value as received in corresponding 
INFORM message 


chaddr 


Set to same value as received in corresponding 
INFORM message 


sname 


Set to Server Host name 


file 


Set to Client Boot File Name 


options 

- code 

- len 
-Type 


* 

53 (DHCP Message Type) 

1 

5 (DHCP ACK) 



'■ Note: 



Additional options included in response to options requested by UE 
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Annex C (normative): 
Generic Test Procedure 

This Annex contains information about generic test procedures. 



C.1 Introduction 



This annex specifies the general test procedure required to get the UE to activate PDP context, discover P-CSCF and 
register to IMS services. Since 3GPP TS 24.229[10] specifies two options for both PDP context activation and P-CSCF 
discovery, the UE specific general test procedure depends on the option selected by the UE. 



C.2 Generic Registration Test Procedure 

The generic test procedure: 

1 The UE sends an Activate PDP Context Request message. In the Protocol Configuration Options IE the IM 
CN Subsystem Signalling Flag may be set or not set, a request for P-CSCF Address or a request for DNS Server 
Address may be included or not. 

2 The SS responds with an Activate PDP Context Accept message. In the Protocol Configuration Options IE 
the IM CN Subsystem Signalling Flag shall not be set, a list of P-CSCF addresses or DNS Server addresses shall 
only be included if a corresponding request was included in step 1 . 

3 Optional P-CSCF address discovery using the DHCP procedure according to Annex C.3 for IPv6 or Annex 
C.4 for IPv4. 

4 The UE initiates IMS registration. SS waits for the UE to send an initial REGISTER request. 

5 The SS responds to the initial REGISTER request with a valid 401 Unauthorized response. 

6 The SS waits for the UE to set up a temporary set of security associations and to send another REGISTER 
request, over those security associations. 

7 The SS responds to the second REGISTER request with valid 200 OK response, sent over the same 
temporary set of security associations that the UE used for sending the REGISTER request. 

8 The SS waits for the UE to send a SUBSCRIBE request over the newly established security associations. 

9 The SS responds to the SUBSCRIBE request with a valid 200 OK response. 

10 The SS sends a valid NOTIFY request for the subscribed registration event package. 

1 1 The SS waits for the UE to respond to the NOTIFY with a 200 OK response. 
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Expected sequence 



Step 


Direction 


Message 


Comment 


UE 1 SS 


1 


^ 


Activate PDP Context Request 


In the Protocol Configuration Options IE the IIVI CN 
Subsystem Signalling Flag may be set or not set, a 
request for P-CSCF Address or a request for DNS 
Server Address may be included or not. 


2 


-^ 


Activate PDP Context Accept 


In the Protocol Configuration Options IE the IM CN 
Subsystem Signalling Flag shall not be set, 
a list of P-CSCF IP addresses or DNS Server 
addresses shall only be included if a corresponding 
request was included in step 1. 


3 






Optional P-CSCF address discovery using the 
DHCP procedure according to Annex C.3 for IPv6 
or Annex C.4 for IPv4. 


4 


-> 


REGISTER 


The UE sends initial registration for IMS services. 


5 


-^ 


401 Unauthorized 


The SS responds with a valid AKAv1-IVID5 
authentication challenge and security mechanisms 
supported by the network. 


6 


^ 


REGISTER 


The UE completes the security negotiation 
procedures, sets up a temporary set of SAs and 
uses those for sending another REGISTER with 
AKAv1-MD5 credentials. 


7 


<r 


200 OK 


The SS responds with 200 OK. 


8 


■^ 


SUBSCRIBE 


The UE subscribes to its registration event 
package. 


9 


^ 


200 OK 


The SS responds with 200 OK. 


10 


^ 


NOTIFY 


The SS sends initial NOTIFY for registration event 
package, containing full registration state 
information for the registered public user identity in 
the XML body 


11 


^ 


200 OK 


The UE responds with 200 OK. 



NOTE: The default message contents in annex A are used. 
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C.3 Generic DHCP test procedure for IPv6 

The generic test procedure (according to RFC 3315[23 

1 The UE sends a DHCPSOLICT message requesting to resolve P-CSCF Domain Name(s). 

2 The SS responds with a DHCPADVERTISE message containing the IP address of the SS as P-CSCF address, if 
the UE requested the SIP Servers option within the DHCPSOLICIT message. 

3 The UE may send a DHCPINFORMATION-REQUEST message . 

4 The SS responds with a DHCPREPLY message containing the IP address of the SS as P-CSCF address. 

Expected sequence 



Step 


Direction 


Message 


Comment 


UE 1 SS 


1 


^ 


DHCPSOLICIT 


Requesting to locate a DHCP server 


2 


^ 


DHCPADVERTISE 




3 


-> 


DHCPINFORMATION-REQUEST 


Optional message. 


4 


^ 


DHCPREPLY 


Sent if DHCPINFORMATION-REOUEST is 
received. 



NOTE: The default message contents in annex B are used. 



C.4 Generic DHCP test procedure for IPv4 

The generic test procedure (according to RFC 2131 [55]): 

1 If the UE already knows a DHCP server address, it goes to step 3. Otherwise, the UE sends a DHCPDISCOVER 
message locating a server. 

2 The SS responds with a DHCPOFFER message. 

3 The UE sends a DHCPINFORM message requesting P-CSCF address(es) in the options field. 

4 The SS responds with a DHCPACK message providing the IP address of the SS as P-CSCF address. 

Expected sequence 



Step 


Direction 


Message 


Comment 


UE 1 SS 


1 


^ 


DHCPDISCOVER 


Optionally sent if UE does not have DHCP server 
address. 


2 


^ 


DHCPOFFER 


Sent if DHCP Discover message is received. 


3 


^ 


DHCPINFORM 


Requesting P-CSCF Address(es). 


4 


^ 


DHCPACK 


Including P-CSCF IP Address. 



NOTE: The default message contents in annex B are used. 
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Annex D (Informative): 

Example values for certain IXIT parameters 

This table contains syntactically correct example values for a number of headers and parameters that may be used as 
such by SS when sending downlink messages and checking that the uplink messages would contain the same values. 
These values will be defined as IXIT. 

IMS registration parameters from ISIM application 

pxHomeDomainName sip:3gpp.org 

pxPublicUserldentity sip:localuser@3gpp.org 

pxPrivateUserldentity privateuser@3gpp.org 

IMS registration parameters derived from IMSI when using USIM application TS 23.003 [32] 

pxJMSI 12345611223344 

home domain name sip:ims. mnc123.mcc456.3gppnetwork.org 

public user identity sip:1 234561 1223344@ ims.mnc123.mcc456.3gppnetworl<.org 

private user identity 1234561 1223344@ ims.mnc123.mcc456.3gppnetwork.org 

CSCF domain names 

px_pcscf pcscf.3gpp.org (FDQN tliat resolves to the IP address of SS) 

pxscscf scscf.3gpp.org (FDQN that does not resolve to the IP address of SS) 
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Annex E (informative): 
Change history 



Meeting 
-1st- 
Level 


Doc-lst- 
Level 


CR 


Rev 


Subject 


Cat 


Version 
Current 


Version 
-New 


Doc-2nd- 
Level 


RP-31 


RP-060052 


- 


- 


Update to version 1 .0.0 and present to RAN#31 for 
information 


- 


0.0.1 


1.0.0 


R5-060292 


- 


- 


- 


- 


Update to version 2.0.0 at RAN5#31 


- 


1.0.0 


2.0.0 


R5-061398 


- 


- 


- 


- 


Update to version 2.1.0 during RAN5#31 e-mail 
agreement procedure 


- 


2.0.0 


2.1.0 


R5-061398r1 


RP-32 


RP-060269 






IVICC Editorial clean up version 2.1 .1 - and present 
to RAN#32 for approval to go under revision control 
(as version 5.0.0) 




2.1.0 


2.1.1 




- 


- 


- 


- 


Update to version 5.0.0 after RAN#32 


- 


2.1.1 


5.0.0 


- 
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